aboutsummaryrefslogtreecommitdiff
path: root/arch/arm/plat-omap
diff options
context:
space:
mode:
authorNishanth Menon <nm@ti.com>2009-11-22 10:10:56 -0800
committerTony Lindgren <tony@atomide.com>2009-11-22 10:24:32 -0800
commit2456a10fb3a9b8c9e970b05e6c1370201675da0a (patch)
tree5e213b07b95f0e4a627a29346a6dd0aecce8b78e /arch/arm/plat-omap
parent048f4bd7607eb714d4831f90dea6fd27eac9e494 (diff)
omap3: Introduce OMAP3630
OMAP3630 is the latest in the family of OMAP3 devices and among the changes it introduces are: New OPP levels for new voltage and frequency levels. a bunch of Bug fixes to various modules feature additions, notably with ISP, sDMA etc. Details about the chip is available here: http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12836&contentId=52606 Strategy used: Strategy to introduce this device into Linux was discussed here: Ref: http://marc.info/?t=125343303400003&r=1&w=2 Two approaches were available: a) Consider 3630 generation of devices as a new family of silicon b) Consider 3630 as an offshoot of 3430 family of devices As a common consensus, (b) seems to be more valid for 3630 as: * There are changes which are easily handled by using "FEATURES" infrastructure. For details how to do this, see thread: http://marc.info/?t=125050998500001&r=1&w=2 * Most of existing 34xx infrastructure can be reused(almost 90%+) - so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx()) all over the place - lesser chance of bugs due to reuse of proven code flow - 36xx specific handling can still be done where required within the existing infrastructure NOTE: * If additional 34xx series are added, OMAP3430_REV_ESXXXX can be added on top of the existing 3630 ones are renumbered This patch was tested on SDP3430, boot tested on 3630 platform using 3430sdp defconfig Signed-off-by: Madhusudhan Chikkature Rajashekar <madhu.cr@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com> Cc: Allen Pais <allen.pais@ti.com> Cc: Anand Gadiyar <gadiyar@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Felipe Balbi <felipe.balbi@nokia.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Sanjeev Premi <premi@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Sergio Alberto Aguirre Rodriguez <saaguirre@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Diffstat (limited to 'arch/arm/plat-omap')
-rw-r--r--arch/arm/plat-omap/include/plat/cpu.h6
1 files changed, 6 insertions, 0 deletions
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
index a67439327de..f4f7a2f0c03 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -180,6 +180,7 @@ IS_OMAP_CLASS(34xx, 0x34)
IS_OMAP_SUBCLASS(242x, 0x242)
IS_OMAP_SUBCLASS(243x, 0x243)
IS_OMAP_SUBCLASS(343x, 0x343)
+IS_OMAP_SUBCLASS(363x, 0x363)
#define cpu_is_omap7xx() 0
#define cpu_is_omap15xx() 0
@@ -325,6 +326,7 @@ IS_OMAP_TYPE(3430, 0x3430)
#define cpu_is_omap3525() 0
#define cpu_is_omap3530() 0
#define cpu_is_omap3430() 0
+#define cpu_is_omap3630() 0
/*
* Whether we have MULTI_OMAP1 or not, we still need to distinguish
@@ -389,6 +391,8 @@ IS_OMAP_TYPE(3430, 0x3430)
(omap3_has_sgx()) && \
(!omap3_has_iva()))
# define cpu_is_omap3530() (cpu_is_omap3430())
+# undef cpu_is_omap3630
+# define cpu_is_omap3630() is_omap363x()
#endif
# if defined(CONFIG_ARCH_OMAP4)
@@ -419,6 +423,8 @@ IS_OMAP_TYPE(3430, 0x3430)
#define OMAP3430_REV_ES3_0 0x34303034
#define OMAP3430_REV_ES3_1 0x34304034
+#define OMAP3630_REV_ES1_0 0x36300034
+
#define OMAP35XX_CLASS 0x35000034
#define OMAP3503_REV(v) (OMAP35XX_CLASS | (0x3503 << 16) | (v << 12))
#define OMAP3515_REV(v) (OMAP35XX_CLASS | (0x3515 << 16) | (v << 12))