Re: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* Paul Walmsley p...@pwsan.com [120815 15:27]: Hi On Mon, 9 Jul 2012, Tony Lindgren wrote: Below (untested) is what could be done in the short term. That's fine with me. Do you want to queue it or do you want me to queue it? Probably best for you to take it along with other related patches. Heh these CK_ defines are now running out of the u16 cpu_mask. They really should be replaced with SoC specific lists of clocks rather than bloating the cpu_mask and repeating it for every clock that's compiled in for 800+ times. Frankly, an extra 1.6KB -- uncompressed -- is pretty low on my list of bloat concerns for multi-OMAP kernels. If it were up to me, I'd just change it to a u32 and be done with the problem for the foreseeable future. And then we're wasting that 1.6KB.. I wonder if we could #define CK_OMAP_DUMMY 0 that's always set for non-shared clocks if they only get set in some *_data.c file in a unique way? Paul got any better ideas? Aside from using u32? Not really. As we've discussed in the past, at some point we should convert the clock initialization to using some kind of per-SoC list. But it doesn't seem worth spending too much time on that while the common clock framework conversion is higher priority. Right, let's do the ifdef else thing then. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
On Thu, Aug 16, 2012 at 03:56:42, Paul Walmsley wrote: Hi On Mon, 9 Jul 2012, Tony Lindgren wrote: Below (untested) is what could be done in the short term. That's fine with me. Do you want to queue it or do you want me to queue it? Heh these CK_ defines are now running out of the u16 cpu_mask. They really should be replaced with SoC specific lists of clocks rather than bloating the cpu_mask and repeating it for every clock that's compiled in for 800+ times. Frankly, an extra 1.6KB -- uncompressed -- is pretty low on my list of bloat concerns for multi-OMAP kernels. If it were up to me, I'd just change it to a u32 and be done with the problem for the foreseeable future. I wonder if we could #define CK_OMAP_DUMMY 0 that's always set for non-shared clocks if they only get set in some *_data.c file in a unique way? Paul got any better ideas? Aside from using u32? Not really. As we've discussed in the past, at some point we should convert the clock initialization to using some kind of per-SoC list. But it doesn't seem worth spending too much time on that while the common clock framework conversion is higher priority. This reminds me for AM33xx clock-tree migration to common-clock framework, so just wanted to update on this, I have already converted the clock-tree to common-clock fw, on top of Rajendra's repository. Now waiting on Rajendra for his next series... Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
Hi On Mon, 9 Jul 2012, Tony Lindgren wrote: Below (untested) is what could be done in the short term. That's fine with me. Do you want to queue it or do you want me to queue it? Heh these CK_ defines are now running out of the u16 cpu_mask. They really should be replaced with SoC specific lists of clocks rather than bloating the cpu_mask and repeating it for every clock that's compiled in for 800+ times. Frankly, an extra 1.6KB -- uncompressed -- is pretty low on my list of bloat concerns for multi-OMAP kernels. If it were up to me, I'd just change it to a u32 and be done with the problem for the foreseeable future. I wonder if we could #define CK_OMAP_DUMMY 0 that's always set for non-shared clocks if they only get set in some *_data.c file in a unique way? Paul got any better ideas? Aside from using u32? Not really. As we've discussed in the past, at some point we should convert the clock initialization to using some kind of per-SoC list. But it doesn't seem worth spending too much time on that while the common clock framework conversion is higher priority. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
On Tue, Jul 10, 2012 at 11:27 AM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Mon, Jul 09, 2012 at 16:09:59, Shilimkar, Santosh wrote:
On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath hvaib...@ti.com wrote:
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
From: R Sricharan r.sricha...@ti.com
OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP
architecture. It's a dual core SOC with GIC used for interrupt
handling and with an integrated L2 cache controller.
OMAP5432 is another variant of OMAP5430, with a
memory controller supporting DDR3 and SATA.
Patch includes:
- The machine specific headers and sources updates.
- Platform header updates.
- Minimum initialisation support for serial.
- IO table init
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
[..]
+#if defined(CONFIG_SOC_OMAP5)
+static struct omap_globals omap5_globals = {
+ .class = OMAP54XX_CLASS,
+ .tap= OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
+ .ctrl = OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
+ .ctrl_pad = OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE),
+ .prm= OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE),
+ .cm = OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_AON_BASE),
+ .cm2= OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE),
+ .prcm_mpu = OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE),
I am not sure whether we had discussed on this before, couldn't find it.
Why don't we reuse OMAP4 data here and elsewhere??
Because data is not same between OMAP4 and OMAP5.
Wherever it is same, it is taken care.
Above most of the base-addresses are same as omap4.
And what about clocktree and hwmod? Is it going tobe same as omap4?
Or we have separate data generated?
The data generated is different for OMAP5. Hwmod, powerdomain, clockdomain,
muxes. This data is out of the tree now since we are waiting for ES2.0
data which
has some differences w.r.t ES1.0. This was discussed in the beginning
as part of this
series review on the list.
[..]
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 70cf825..766181c 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -6,8 +6,8 @@
* Copyright (C) 2005 Nokia Corporation
* Written by Tony Lindgren t...@atomide.com
*
- * Copyright (C) 2009 Texas Instruments
- * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
+ * Copyright (C) 2009-2012 Texas Instruments
+ * Added OMAP4/5 support - Santosh Shilimkar santosh.shilim...@ti.com
*
* 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
@@ -44,6 +44,7 @@
#else
#define OMAP4_SRAM_PUB_PA(OMAP4_SRAM_PA + 0x4000)
#endif
+#define OMAP5_SRAM_PA0x4030
We have mix of such definitions here, for example,
arch/arm/plat-omap/include/plat/sram.h
and now in arch/arm/plat-omap/sram.c here itself.
May be right time to clean it up now.
Thats because of an interconnect BUG which needed it exported
at plat level in case of OMAP4.
Not only omap4, but we have 2, 3, 4 and AM33xx definitions present there
at plat/sram.h and public PA (SRAM_PUB_PA) address is defined in sram.c file.
I see that now. Infact there is no need for any of those PA's to be defined
there except OMAP4 which needs to have that macro available for an errata.
I will clean that up once the series is merged. Don't want to introduce any
regression in last moment changes.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
On Tue, Jul 10, 2012 at 11:36:15, Shilimkar, Santosh wrote:
On Tue, Jul 10, 2012 at 11:27 AM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Mon, Jul 09, 2012 at 16:09:59, Shilimkar, Santosh wrote:
On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath hvaib...@ti.com wrote:
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
From: R Sricharan r.sricha...@ti.com
OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP
architecture. It's a dual core SOC with GIC used for interrupt
handling and with an integrated L2 cache controller.
OMAP5432 is another variant of OMAP5430, with a
memory controller supporting DDR3 and SATA.
Patch includes:
- The machine specific headers and sources updates.
- Platform header updates.
- Minimum initialisation support for serial.
- IO table init
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
[..]
+#if defined(CONFIG_SOC_OMAP5)
+static struct omap_globals omap5_globals = {
+ .class = OMAP54XX_CLASS,
+ .tap= OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
+ .ctrl = OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
+ .ctrl_pad = OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE),
+ .prm= OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE),
+ .cm = OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_AON_BASE),
+ .cm2= OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE),
+ .prcm_mpu = OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE),
I am not sure whether we had discussed on this before, couldn't find it.
Why don't we reuse OMAP4 data here and elsewhere??
Because data is not same between OMAP4 and OMAP5.
Wherever it is same, it is taken care.
Above most of the base-addresses are same as omap4.
And what about clocktree and hwmod? Is it going tobe same as omap4?
Or we have separate data generated?
The data generated is different for OMAP5. Hwmod, powerdomain, clockdomain,
muxes. This data is out of the tree now since we are waiting for ES2.0
data which
has some differences w.r.t ES1.0.
Ok, this is useful information.
This was discussed in the beginning
as part of this
series review on the list.
My bad, I missed that discussion, and will refer to archives now.
[..]
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 70cf825..766181c 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -6,8 +6,8 @@
* Copyright (C) 2005 Nokia Corporation
* Written by Tony Lindgren t...@atomide.com
*
- * Copyright (C) 2009 Texas Instruments
- * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
+ * Copyright (C) 2009-2012 Texas Instruments
+ * Added OMAP4/5 support - Santosh Shilimkar
santosh.shilim...@ti.com
*
* 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
@@ -44,6 +44,7 @@
#else
#define OMAP4_SRAM_PUB_PA(OMAP4_SRAM_PA + 0x4000)
#endif
+#define OMAP5_SRAM_PA0x4030
We have mix of such definitions here, for example,
arch/arm/plat-omap/include/plat/sram.h
and now in arch/arm/plat-omap/sram.c here itself.
May be right time to clean it up now.
Thats because of an interconnect BUG which needed it exported
at plat level in case of OMAP4.
Not only omap4, but we have 2, 3, 4 and AM33xx definitions present there
at plat/sram.h and public PA (SRAM_PUB_PA) address is defined in sram.c
file.
I see that now. Infact there is no need for any of those PA's to be defined
there except OMAP4 which needs to have that macro available for an errata.
I will clean that up once the series is merged. Don't want to introduce any
regression in last moment changes.
I am ok.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
On Mon, Jul 09, 2012 at 18:41:58, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [120709 01:55]:
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -39,6 +39,7 @@ struct omap_clk {
#define CK_443X (1 11)
#define CK_TI816X(1 12)
#define CK_446X (1 13)
+#define CK_54XX (1 14)
This is conflicting with AM33XX, you may want to rebase it again, since
AM33xx clock tree is already pushed and available in
linux-omap/devel-am33xx-part2.
Heh these CK_ defines are now running out of the u16 cpu_mask.
They really should be replaced with SoC specific lists of clocks
rather than bloating the cpu_mask and repeating it for every clock
that's compiled in for 800+ times.
Below (untested) is what could be done in the short term.
I wonder if we could #define CK_OMAP_DUMMY 0 that's always set
for non-shared clocks if they only get set in some *_data.c
file in a unique way?
Paul got any better ideas?
Regards,
Tony
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -26,26 +26,29 @@ struct omap_clk {
}
/* Platform flags for the clkdev-OMAP integration code */
+
+#ifdef CONFIG_ARCH_OMAP1
#define CK_310 (1 0)
#define CK_7XX (1 1)/* 7xx, 850 */
#define CK_1510 (1 2)
#define CK_16XX (1 3)/* 16xx, 17xx, 5912 */
-#define CK_242X (1 4)
-#define CK_243X (1 5)/* 243x, 253x */
-#define CK_3430ES1 (1 6)/* 34xxES1 only */
-#define CK_3430ES2PLUS (1 7)/* 34xxES2, ES3, non-Sitara
35xx only */
-#define CK_AM35XX(1 9)/* Sitara AM35xx */
-#define CK_36XX (1 10) /* 36xx/37xx-specific clocks */
-#define CK_443X (1 11)
-#define CK_TI816X(1 12)
-#define CK_446X (1 13)
-#define CK_AM33XX(1 14) /* AM33xx specific clocks */
-#define CK_1710 (1 15) /* 1710 extra for rate
selection */
-
+#define CK_1710 (1 4)/* 1710 extra for rate
selection */
+#endif
+#ifdef CONFIG_ARCH_OMAP2PLUS
+#define CK_242X (1 0)
+#define CK_243X (1 1)/* 243x, 253x */
+#define CK_3430ES1 (1 2)/* 34xxES1 only */
+#define CK_3430ES2PLUS (1 3)/* 34xxES2, ES3, non-Sitara
35xx only */
+#define CK_AM35XX(1 4)/* Sitara AM35xx */
+#define CK_36XX (1 5)/* 36xx/37xx-specific clocks */
+#define CK_443X (1 6)
+#define CK_TI816X(1 7)
+#define CK_446X (1 8)
+#define CK_AM33XX(1 9)/* AM33xx specific clocks */
#define CK_34XX (CK_3430ES1 | CK_3430ES2PLUS)
#define CK_3XXX (CK_34XX | CK_AM35XX | CK_36XX)
-
+#endif
#endif
This also will not scale up in the future and will end up again in the same
situation.
Just a quick thought, may work here,
I looked at the usage of cpu_mask and rates.flag and I believe we can
restrict both to given SoC, something like,
OMAP34XX -
ES1
ES2PLUS
36XX
AM35XX
...
OMAP4 -
443X
446X
AM33XX -
AM335X
TI816X
TI814X
...
XYZ... -
...
The proposal would be,
To make cpu_mask and rate.flags 32 bit wide and divide it in 16-16 bits -
Lower 16 bits = describe SoC it is applicable to
Upper 16 bit = describes silicon versions or families
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* Hiremath, Vaibhav hvaib...@ti.com [120709 23:30]:
On Mon, Jul 09, 2012 at 18:41:58, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [120709 01:55]:
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -39,6 +39,7 @@ struct omap_clk {
#define CK_443X(1 11)
#define CK_TI816X (1 12)
#define CK_446X(1 13)
+#define CK_54XX(1 14)
This is conflicting with AM33XX, you may want to rebase it again, since
AM33xx clock tree is already pushed and available in
linux-omap/devel-am33xx-part2.
Heh these CK_ defines are now running out of the u16 cpu_mask.
They really should be replaced with SoC specific lists of clocks
rather than bloating the cpu_mask and repeating it for every clock
that's compiled in for 800+ times.
Below (untested) is what could be done in the short term.
I wonder if we could #define CK_OMAP_DUMMY 0 that's always set
for non-shared clocks if they only get set in some *_data.c
file in a unique way?
Paul got any better ideas?
...
This also will not scale up in the future and will end up again in the same
situation.
Right that's why we want to get rid of it.
Just a quick thought, may work here,
I looked at the usage of cpu_mask and rates.flag and I believe we can
restrict both to given SoC, something like,
OMAP34XX -
ES1
ES2PLUS
36XX
AM35XX
...
OMAP4 -
443X
446X
AM33XX -
AM335X
TI816X
TI814X
...
XYZ... -
...
The proposal would be,
To make cpu_mask and rate.flags 32 bit wide and divide it in 16-16 bits -
Lower 16 bits = describe SoC it is applicable to
Upper 16 bit = describes silicon versions or families
No thanks.. We don't want to make it 32 bit and bloat all the compiled in
clock even further.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
On Tue, Jul 10, 2012 at 13:48:52, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120709 23:30]:
On Mon, Jul 09, 2012 at 18:41:58, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [120709 01:55]:
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -39,6 +39,7 @@ struct omap_clk {
#define CK_443X (1 11)
#define CK_TI816X(1 12)
#define CK_446X (1 13)
+#define CK_54XX (1 14)
This is conflicting with AM33XX, you may want to rebase it again, since
AM33xx clock tree is already pushed and available in
linux-omap/devel-am33xx-part2.
Heh these CK_ defines are now running out of the u16 cpu_mask.
They really should be replaced with SoC specific lists of clocks
rather than bloating the cpu_mask and repeating it for every clock
that's compiled in for 800+ times.
Below (untested) is what could be done in the short term.
I wonder if we could #define CK_OMAP_DUMMY 0 that's always set
for non-shared clocks if they only get set in some *_data.c
file in a unique way?
Paul got any better ideas?
...
This also will not scale up in the future and will end up again in the same
situation.
Right that's why we want to get rid of it.
Just a quick thought, may work here,
I looked at the usage of cpu_mask and rates.flag and I believe we can
restrict both to given SoC, something like,
OMAP34XX -
ES1
ES2PLUS
36XX
AM35XX
...
OMAP4 -
443X
446X
AM33XX -
AM335X
TI816X
TI814X
...
XYZ... -
...
The proposal would be,
To make cpu_mask and rate.flags 32 bit wide and divide it in 16-16 bits -
Lower 16 bits = describe SoC it is applicable to
Upper 16 bit = describes silicon versions or families
No thanks.. We don't want to make it 32 bit and bloat all the compiled in
clock even further.
In that case, how about just get rid of cpu_mask completely and trust the
data passed by clock-tree for clksel dividers?
Let clock-tree data handle this, even if in some cases we end up in
duplicating data for some clocks??
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* Hiremath, Vaibhav hvaib...@ti.com [120710 01:35]: On Tue, Jul 10, 2012 at 13:48:52, Tony Lindgren wrote: No thanks.. We don't want to make it 32 bit and bloat all the compiled in clock even further. In that case, how about just get rid of cpu_mask completely and trust the data passed by clock-tree for clksel dividers? Let clock-tree data handle this, even if in some cases we end up in duplicating data for some clocks?? Yes something like that. We already know which clocks need to be registered, so whatever we still use CK_ for should be also initialized in omap_clk_init() functions. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: From: R Sricharan r.sricha...@ti.com OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP architecture. It's a dual core SOC with GIC used for interrupt handling and with an integrated L2 cache controller. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. Patch includes: - The machine specific headers and sources updates. - Platform header updates. - Minimum initialisation support for serial. - IO table init Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/Makefile | 23 ++--- arch/arm/mach-omap2/common.c | 24 + arch/arm/mach-omap2/common.h | 11 ++ arch/arm/mach-omap2/include/mach/debug-macro.S |8 ++--- arch/arm/mach-omap2/io.c | 44 arch/arm/mach-omap2/iomap.h| 27 +++ arch/arm/mach-omap2/omap_hwmod.c |2 +- arch/arm/mach-omap2/prcm-common.h |2 +- arch/arm/mach-omap2/prcm.c |2 +- arch/arm/plat-omap/include/plat/clkdev_omap.h |1 + arch/arm/plat-omap/include/plat/clock.h|1 + arch/arm/plat-omap/include/plat/hardware.h |1 + arch/arm/plat-omap/include/plat/multi.h|9 + arch/arm/plat-omap/include/plat/omap54xx.h | 32 + arch/arm/plat-omap/include/plat/serial.h | 10 ++ arch/arm/plat-omap/include/plat/uncompress.h |6 arch/arm/plat-omap/sram.c | 11 -- 17 files changed, 200 insertions(+), 14 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/omap54xx.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 240f196..085e171 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -17,6 +17,7 @@ obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common) obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common) obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common) obj-$(CONFIG_SOC_AM33XX) += irq.o $(hwmod-common) +obj-$(CONFIG_SOC_OMAP5) += prm44xx.o $(hwmod-common) $(secure-common) ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) obj-y += mcbsp.o @@ -29,8 +30,10 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC) += sdrc.o obj-$(CONFIG_SMP)+= omap-smp.o omap-headsmp.o obj-$(CONFIG_HOTPLUG_CPU)+= omap-hotplug.o -obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o -obj-$(CONFIG_ARCH_OMAP4) += sleep44xx.o +omap-4-5-common = omap4-common.o omap-wakeupgen.o \ +sleep44xx.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common) +obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-common) plus_sec := $(call as-instr,.arch_extension sec,+sec) AFLAGS_omap-headsmp.o:=-Wa,-march=armv7-a$(plus_sec) @@ -70,6 +73,7 @@ obj-$(CONFIG_ARCH_OMAP2)+= sleep24xx.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o obj-$(CONFIG_ARCH_OMAP3) += cpuidle34xx.o obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o +obj-$(CONFIG_SOC_OMAP5) += omap-mpuss-lowpower.o obj-$(CONFIG_ARCH_OMAP4) += cpuidle44xx.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o @@ -85,14 +89,16 @@ endif endif # PRCM +omap-prcm-4-5-common = prcm.o cminst44xx.o cm44xx.o \ +prcm_mpu44xx.o prminst44xx.o \ +vc44xx_data.o vp44xx_data.o obj-y+= prm_common.o obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o -obj-$(CONFIG_ARCH_OMAP4) += prcm.o cminst44xx.o cm44xx.o -obj-$(CONFIG_ARCH_OMAP4) += prcm_mpu44xx.o prminst44xx.o -obj-$(CONFIG_ARCH_OMAP4) += vc44xx_data.o vp44xx_data.o prm44xx.o obj-$(CONFIG_SOC_AM33XX) += prcm.o prm33xx.o cm33xx.o +obj-$(CONFIG_ARCH_OMAP4) += $(omap-prcm-4-5-common) prm44xx.o +obj-$(CONFIG_SOC_OMAP5) += $(omap-prcm-4-5-common) # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o @@ -104,6 +110,7 @@ obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) obj-$(CONFIG_ARCH_OMAP4) += voltagedomains44xx_data.o obj-$(CONFIG_SOC_AM33XX) +=
Re: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath hvaib...@ti.com wrote:
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
From: R Sricharan r.sricha...@ti.com
OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP
architecture. It's a dual core SOC with GIC used for interrupt
handling and with an integrated L2 cache controller.
OMAP5432 is another variant of OMAP5430, with a
memory controller supporting DDR3 and SATA.
Patch includes:
- The machine specific headers and sources updates.
- Platform header updates.
- Minimum initialisation support for serial.
- IO table init
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
[..]
+#if defined(CONFIG_SOC_OMAP5)
+static struct omap_globals omap5_globals = {
+ .class = OMAP54XX_CLASS,
+ .tap= OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
+ .ctrl = OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
+ .ctrl_pad = OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE),
+ .prm= OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE),
+ .cm = OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_AON_BASE),
+ .cm2= OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE),
+ .prcm_mpu = OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE),
I am not sure whether we had discussed on this before, couldn't find it.
Why don't we reuse OMAP4 data here and elsewhere??
Because data is not same between OMAP4 and OMAP5.
Wherever it is same, it is taken care.
[..]
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 70cf825..766181c 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -6,8 +6,8 @@
* Copyright (C) 2005 Nokia Corporation
* Written by Tony Lindgren t...@atomide.com
*
- * Copyright (C) 2009 Texas Instruments
- * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
+ * Copyright (C) 2009-2012 Texas Instruments
+ * Added OMAP4/5 support - Santosh Shilimkar santosh.shilim...@ti.com
*
* 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
@@ -44,6 +44,7 @@
#else
#define OMAP4_SRAM_PUB_PA(OMAP4_SRAM_PA + 0x4000)
#endif
+#define OMAP5_SRAM_PA0x4030
We have mix of such definitions here, for example,
arch/arm/plat-omap/include/plat/sram.h
and now in arch/arm/plat-omap/sram.c here itself.
May be right time to clean it up now.
Thats because of an interconnect BUG which needed it exported
at plat level in case of OMAP4.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* Vaibhav Hiremath hvaib...@ti.com [120709 01:55]:
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -39,6 +39,7 @@ struct omap_clk {
#define CK_443X(1 11)
#define CK_TI816X (1 12)
#define CK_446X(1 13)
+#define CK_54XX(1 14)
This is conflicting with AM33XX, you may want to rebase it again, since
AM33xx clock tree is already pushed and available in
linux-omap/devel-am33xx-part2.
Heh these CK_ defines are now running out of the u16 cpu_mask.
They really should be replaced with SoC specific lists of clocks
rather than bloating the cpu_mask and repeating it for every clock
that's compiled in for 800+ times.
Below (untested) is what could be done in the short term.
I wonder if we could #define CK_OMAP_DUMMY 0 that's always set
for non-shared clocks if they only get set in some *_data.c
file in a unique way?
Paul got any better ideas?
Regards,
Tony
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -26,26 +26,29 @@ struct omap_clk {
}
/* Platform flags for the clkdev-OMAP integration code */
+
+#ifdef CONFIG_ARCH_OMAP1
#define CK_310 (1 0)
#define CK_7XX (1 1)/* 7xx, 850 */
#define CK_1510(1 2)
#define CK_16XX(1 3)/* 16xx, 17xx, 5912 */
-#define CK_242X(1 4)
-#define CK_243X(1 5)/* 243x, 253x */
-#define CK_3430ES1 (1 6)/* 34xxES1 only */
-#define CK_3430ES2PLUS (1 7)/* 34xxES2, ES3, non-Sitara 35xx only */
-#define CK_AM35XX (1 9)/* Sitara AM35xx */
-#define CK_36XX(1 10) /* 36xx/37xx-specific clocks */
-#define CK_443X(1 11)
-#define CK_TI816X (1 12)
-#define CK_446X(1 13)
-#define CK_AM33XX (1 14) /* AM33xx specific clocks */
-#define CK_1710(1 15) /* 1710 extra for rate
selection */
-
+#define CK_1710(1 4)/* 1710 extra for rate
selection */
+#endif
+#ifdef CONFIG_ARCH_OMAP2PLUS
+#define CK_242X(1 0)
+#define CK_243X(1 1)/* 243x, 253x */
+#define CK_3430ES1 (1 2)/* 34xxES1 only */
+#define CK_3430ES2PLUS (1 3)/* 34xxES2, ES3, non-Sitara 35xx only */
+#define CK_AM35XX (1 4)/* Sitara AM35xx */
+#define CK_36XX(1 5)/* 36xx/37xx-specific clocks */
+#define CK_443X(1 6)
+#define CK_TI816X (1 7)
+#define CK_446X(1 8)
+#define CK_AM33XX (1 9)/* AM33xx specific clocks */
#define CK_34XX(CK_3430ES1 | CK_3430ES2PLUS)
#define CK_3XXX(CK_34XX | CK_AM35XX | CK_36XX)
-
+#endif
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* Tony Lindgren t...@atomide.com [120709 06:17]:
* Vaibhav Hiremath hvaib...@ti.com [120709 01:55]:
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -39,6 +39,7 @@ struct omap_clk {
#define CK_443X (1 11)
#define CK_TI816X(1 12)
#define CK_446X (1 13)
+#define CK_54XX (1 14)
This is conflicting with AM33XX, you may want to rebase it again, since
AM33xx clock tree is already pushed and available in
linux-omap/devel-am33xx-part2.
Heh these CK_ defines are now running out of the u16 cpu_mask.
They really should be replaced with SoC specific lists of clocks
rather than bloating the cpu_mask and repeating it for every clock
that's compiled in for 800+ times.
Below (untested) is what could be done in the short term.
I wonder if we could #define CK_OMAP_DUMMY 0 that's always set
for non-shared clocks if they only get set in some *_data.c
file in a unique way?
Paul got any better ideas?
Santosh, I suggest you just drop the CK_54XX change from your patches
as the clock fwk support will need further patching and is not used
yet.
Regards,
Tony
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -26,26 +26,29 @@ struct omap_clk {
}
/* Platform flags for the clkdev-OMAP integration code */
+
+#ifdef CONFIG_ARCH_OMAP1
#define CK_310 (1 0)
#define CK_7XX (1 1)/* 7xx, 850 */
#define CK_1510 (1 2)
#define CK_16XX (1 3)/* 16xx, 17xx, 5912 */
-#define CK_242X (1 4)
-#define CK_243X (1 5)/* 243x, 253x */
-#define CK_3430ES1 (1 6)/* 34xxES1 only */
-#define CK_3430ES2PLUS (1 7)/* 34xxES2, ES3, non-Sitara
35xx only */
-#define CK_AM35XX(1 9)/* Sitara AM35xx */
-#define CK_36XX (1 10) /* 36xx/37xx-specific clocks */
-#define CK_443X (1 11)
-#define CK_TI816X(1 12)
-#define CK_446X (1 13)
-#define CK_AM33XX(1 14) /* AM33xx specific clocks */
-#define CK_1710 (1 15) /* 1710 extra for rate
selection */
-
+#define CK_1710 (1 4)/* 1710 extra for rate
selection */
+#endif
+#ifdef CONFIG_ARCH_OMAP2PLUS
+#define CK_242X (1 0)
+#define CK_243X (1 1)/* 243x, 253x */
+#define CK_3430ES1 (1 2)/* 34xxES1 only */
+#define CK_3430ES2PLUS (1 3)/* 34xxES2, ES3, non-Sitara
35xx only */
+#define CK_AM35XX(1 4)/* Sitara AM35xx */
+#define CK_36XX (1 5)/* 36xx/37xx-specific clocks */
+#define CK_443X (1 6)
+#define CK_TI816X(1 7)
+#define CK_446X (1 8)
+#define CK_AM33XX(1 9)/* AM33xx specific clocks */
#define CK_34XX (CK_3430ES1 | CK_3430ES2PLUS)
#define CK_3XXX (CK_34XX | CK_AM35XX | CK_36XX)
-
+#endif
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
On Mon, Jul 9, 2012 at 6:55 PM, Tony Lindgren t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [120709 06:17]:
* Vaibhav Hiremath hvaib...@ti.com [120709 01:55]:
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -39,6 +39,7 @@ struct omap_clk {
#define CK_443X (1 11)
#define CK_TI816X(1 12)
#define CK_446X (1 13)
+#define CK_54XX (1 14)
This is conflicting with AM33XX, you may want to rebase it again, since
AM33xx clock tree is already pushed and available in
linux-omap/devel-am33xx-part2.
Heh these CK_ defines are now running out of the u16 cpu_mask.
They really should be replaced with SoC specific lists of clocks
rather than bloating the cpu_mask and repeating it for every clock
that's compiled in for 800+ times.
Below (untested) is what could be done in the short term.
I wonder if we could #define CK_OMAP_DUMMY 0 that's always set
for non-shared clocks if they only get set in some *_data.c
file in a unique way?
Paul got any better ideas?
Santosh, I suggest you just drop the CK_54XX change from your patches
as the clock fwk support will need further patching and is not used
yet.
Good idea. Will have a look at it.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
On Mon, Jul 9, 2012 at 6:56 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Mon, Jul 9, 2012 at 6:55 PM, Tony Lindgren t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [120709 06:17]:
* Vaibhav Hiremath hvaib...@ti.com [120709 01:55]:
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -39,6 +39,7 @@ struct omap_clk {
#define CK_443X (1 11)
#define CK_TI816X(1 12)
#define CK_446X (1 13)
+#define CK_54XX (1 14)
This is conflicting with AM33XX, you may want to rebase it again, since
AM33xx clock tree is already pushed and available in
linux-omap/devel-am33xx-part2.
Heh these CK_ defines are now running out of the u16 cpu_mask.
They really should be replaced with SoC specific lists of clocks
rather than bloating the cpu_mask and repeating it for every clock
that's compiled in for 800+ times.
Below (untested) is what could be done in the short term.
I wonder if we could #define CK_OMAP_DUMMY 0 that's always set
for non-shared clocks if they only get set in some *_data.c
file in a unique way?
Paul got any better ideas?
Santosh, I suggest you just drop the CK_54XX change from your patches
as the clock fwk support will need further patching and is not used
yet.
Good idea. Will have a look at it.
I dropped the CK_54XX and RATE hunks from the patch. Updated
patch below for the record.
Regards
Santosh
--
From 05e152c76a1efaa3165afecf5acf535c8283f386 Mon Sep 17 00:00:00 2001
From: R Sricharan r.sricha...@ti.com
Date: Tue, 5 Jun 2012 16:21:32 +0530
Subject: [PATCH 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP
architecture. It's a dual core SOC with GIC used for interrupt
handling and with an integrated L2 cache controller.
OMAP5432 is another variant of OMAP5430, with a
memory controller supporting DDR3 and SATA.
Patch includes:
- The machine specific headers and sources updates.
- Platform header updates.
- Minimum initialisation support for serial.
- IO table init
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Makefile | 23 ++---
arch/arm/mach-omap2/common.c | 24 +
arch/arm/mach-omap2/common.h | 11 ++
arch/arm/mach-omap2/include/mach/debug-macro.S |8 ++---
arch/arm/mach-omap2/io.c | 44
arch/arm/mach-omap2/iomap.h| 27 +++
arch/arm/mach-omap2/omap_hwmod.c |2 +-
arch/arm/mach-omap2/prcm-common.h |2 +-
arch/arm/mach-omap2/prcm.c |2 +-
arch/arm/plat-omap/include/plat/hardware.h |1 +
arch/arm/plat-omap/include/plat/multi.h|9 +
arch/arm/plat-omap/include/plat/omap54xx.h | 32 +
arch/arm/plat-omap/include/plat/serial.h | 10 ++
arch/arm/plat-omap/include/plat/uncompress.h |6
arch/arm/plat-omap/sram.c | 11 --
15 files changed, 198 insertions(+), 14 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/omap54xx.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 240f196..085e171 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common)
obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common)
obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common)
obj-$(CONFIG_SOC_AM33XX) += irq.o $(hwmod-common)
+obj-$(CONFIG_SOC_OMAP5) += prm44xx.o $(hwmod-common) $(secure-common)
ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),)
obj-y += mcbsp.o
@@ -29,8 +30,10 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC) += sdrc.o
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o
-obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o
-obj-$(CONFIG_ARCH_OMAP4) += sleep44xx.o
+omap-4-5-common= omap4-common.o
omap-wakeupgen.o \
+ sleep44xx.o
+obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common)
+obj-$(CONFIG_SOC_OMAP5)+= $(omap-4-5-common)
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec)
@@ -70,6 +73,7 @@ obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
obj-$(CONFIG_ARCH_OMAP3) += cpuidle34xx.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
+obj-$(CONFIG_SOC_OMAP5)
RE: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
On Mon, Jul 09, 2012 at 16:09:59, Shilimkar, Santosh wrote:
On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath hvaib...@ti.com wrote:
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
From: R Sricharan r.sricha...@ti.com
OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP
architecture. It's a dual core SOC with GIC used for interrupt
handling and with an integrated L2 cache controller.
OMAP5432 is another variant of OMAP5430, with a
memory controller supporting DDR3 and SATA.
Patch includes:
- The machine specific headers and sources updates.
- Platform header updates.
- Minimum initialisation support for serial.
- IO table init
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
[..]
+#if defined(CONFIG_SOC_OMAP5)
+static struct omap_globals omap5_globals = {
+ .class = OMAP54XX_CLASS,
+ .tap= OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
+ .ctrl = OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
+ .ctrl_pad = OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE),
+ .prm= OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE),
+ .cm = OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_AON_BASE),
+ .cm2= OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE),
+ .prcm_mpu = OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE),
I am not sure whether we had discussed on this before, couldn't find it.
Why don't we reuse OMAP4 data here and elsewhere??
Because data is not same between OMAP4 and OMAP5.
Wherever it is same, it is taken care.
Above most of the base-addresses are same as omap4.
And what about clocktree and hwmod? Is it going tobe same as omap4?
Or we have separate data generated?
[..]
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 70cf825..766181c 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -6,8 +6,8 @@
* Copyright (C) 2005 Nokia Corporation
* Written by Tony Lindgren t...@atomide.com
*
- * Copyright (C) 2009 Texas Instruments
- * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
+ * Copyright (C) 2009-2012 Texas Instruments
+ * Added OMAP4/5 support - Santosh Shilimkar santosh.shilim...@ti.com
*
* 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
@@ -44,6 +44,7 @@
#else
#define OMAP4_SRAM_PUB_PA(OMAP4_SRAM_PA + 0x4000)
#endif
+#define OMAP5_SRAM_PA0x4030
We have mix of such definitions here, for example,
arch/arm/plat-omap/include/plat/sram.h
and now in arch/arm/plat-omap/sram.c here itself.
May be right time to clean it up now.
Thats because of an interconnect BUG which needed it exported
at plat level in case of OMAP4.
Not only omap4, but we have 2, 3, 4 and AM33xx definitions present there
at plat/sram.h and public PA (SRAM_PUB_PA) address is defined in sram.c file.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
