* [RFC PATCH-V2 0/4] Introducing TI's New SoC/board AM335XEVM
@ 2011-08-29 12:46 ` hvaibhav at ti.com
2011-09-15 0:32 ` Tony Lindgren
0 siblings, 1 reply; 57+ messages in thread
From: hvaibhav at ti.com @ 2011-08-29 12:46 UTC (permalink / raw)
To: linux-arm-kernel
From: Vaibhav Hiremath <hvaibhav@ti.com>
This patch set adds support for AM335x device having
Cortex-A8 MPU.
AM335X is treated as another OMAP3 variant, where,
along with existing cpu class OMAP34XX, new cpu class AM33XX is created
and the respective type is AM335X, which is newly added device in the family.
This means, cpu_is_omap34xx(), cpu_is_am33xx() and
cpu_is_am335x() checks return success for AM335X.
Currently submitting this patch series as a RFC (V2), to initiate the
discussion on the approach we have chosen for AM335x device support.
Based on the feedback, will submit the final version of patch series
immediately.
This patch series is created on top of linux-omap/master and
Hemant's TI814X patches submitted recently.
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg53457.html
Also, I have validated OMAP3 boot test with this patch-series on OMAP3EVM.
Changes from V1:
- Created separate cpu/SoC class for AM33XX family of devices,
due to all known facts. This is been mentioned in main-chain
https://patchwork.kernel.org/patch/1056312/
- BUG Fix in debug-macro.S, which was leading to build failure.
https://patchwork.kernel.org/patch/1056302/
Afzal Mohammed (4):
AM335X: Update common omap platform files
AM335X: Update common OMAP machine specific sources
AM335X: Create board support and enable build for AM335XEVM
AM335X: Add low level debugging support
arch/arm/mach-omap2/Kconfig | 10 ++++
arch/arm/mach-omap2/Makefile | 2 +
arch/arm/mach-omap2/board-am335xevm.c | 57 ++++++++++++++++++++++++
arch/arm/mach-omap2/clock3xxx_data.c | 3 +
arch/arm/mach-omap2/common.c | 16 +++++++
arch/arm/mach-omap2/id.c | 6 +++
arch/arm/mach-omap2/include/mach/debug-macro.S | 22 +++++++++
arch/arm/mach-omap2/io.c | 25 ++++++++++
arch/arm/plat-omap/include/plat/am33xx.h | 25 ++++++++++
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/common.h | 1 +
arch/arm/plat-omap/include/plat/cpu.h | 23 ++++++++++
arch/arm/plat-omap/include/plat/hardware.h | 1 +
arch/arm/plat-omap/include/plat/io.h | 20 ++++++++
arch/arm/plat-omap/include/plat/omap34xx.h | 2 +
arch/arm/plat-omap/include/plat/serial.h | 4 ++
arch/arm/plat-omap/include/plat/uncompress.h | 6 +++
arch/arm/plat-omap/io.c | 3 +
19 files changed, 228 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-am335xevm.c
create mode 100644 arch/arm/plat-omap/include/plat/am33xx.h
^ permalink raw reply [flat|nested] 57+ messages in thread* [RFC PATCH-V2 0/4] Introducing TI's New SoC/board AM335XEVM
2011-08-29 12:46 ` [RFC PATCH-V2 0/4] Introducing TI's New SoC/board AM335XEVM hvaibhav at ti.com
@ 2011-09-15 0:32 ` Tony Lindgren
2011-09-15 7:13 ` Hiremath, Vaibhav
0 siblings, 1 reply; 57+ messages in thread
From: Tony Lindgren @ 2011-09-15 0:32 UTC (permalink / raw)
To: linux-arm-kernel
* hvaibhav at ti.com <hvaibhav@ti.com> [110829 05:52]:
> From: Vaibhav Hiremath <hvaibhav@ti.com>
>
> This patch set adds support for AM335x device having
> Cortex-A8 MPU.
>
> AM335X is treated as another OMAP3 variant, where,
> along with existing cpu class OMAP34XX, new cpu class AM33XX is created
> and the respective type is AM335X, which is newly added device in the family.
> This means, cpu_is_omap34xx(), cpu_is_am33xx() and
> cpu_is_am335x() checks return success for AM335X.
>
> Currently submitting this patch series as a RFC (V2), to initiate the
> discussion on the approach we have chosen for AM335x device support.
> Based on the feedback, will submit the final version of patch series
> immediately.
Can you please rebase these on Paul's CHIP_IS removal series?
Those patches are available at:
git://git.pwsan.com/linux-2.6 omap_chip_remove_cleanup_3.2
Regards,
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [RFC PATCH-V2 0/4] Introducing TI's New SoC/board AM335XEVM
2011-09-15 0:32 ` Tony Lindgren
@ 2011-09-15 7:13 ` Hiremath, Vaibhav
0 siblings, 0 replies; 57+ messages in thread
From: Hiremath, Vaibhav @ 2011-09-15 7:13 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Thursday, September 15, 2011 6:02 AM
> To: Hiremath, Vaibhav
> Cc: linux-omap at vger.kernel.org; Hilman, Kevin; paul at pwsan.com; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [RFC PATCH-V2 0/4] Introducing TI's New SoC/board AM335XEVM
>
> * hvaibhav at ti.com <hvaibhav@ti.com> [110829 05:52]:
> > From: Vaibhav Hiremath <hvaibhav@ti.com>
> >
> > This patch set adds support for AM335x device having
> > Cortex-A8 MPU.
> >
> > AM335X is treated as another OMAP3 variant, where,
> > along with existing cpu class OMAP34XX, new cpu class AM33XX is created
> > and the respective type is AM335X, which is newly added device in the
> family.
> > This means, cpu_is_omap34xx(), cpu_is_am33xx() and
> > cpu_is_am335x() checks return success for AM335X.
> >
> > Currently submitting this patch series as a RFC (V2), to initiate the
> > discussion on the approach we have chosen for AM335x device support.
> > Based on the feedback, will submit the final version of patch series
> > immediately.
>
> Can you please rebase these on Paul's CHIP_IS removal series?
>
> Those patches are available at:
>
> git://git.pwsan.com/linux-2.6 omap_chip_remove_cleanup_3.2
>
[Hiremath, Vaibhav] Thanks Tony for your comments,
Yeah, I will rebase and submit it again ASAP.
Thanks,
Vaibhav
> Regards,
>
> Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V3 1/4] arm:omap:am33xx: Update common omap platform files
@ 2011-09-20 14:32 ` hvaibhav at ti.com
2011-10-06 23:03 ` Tony Lindgren
0 siblings, 1 reply; 57+ messages in thread
From: hvaibhav at ti.com @ 2011-09-20 14:32 UTC (permalink / raw)
To: linux-arm-kernel
From: Afzal Mohammed <afzal@ti.com>
This patch updates the common platform files with AM335X device
support (AM33XX family).
The approach taken in this patch is,
AM33XX device will be considered as OMAP3 variant, and a separate
SoC class created for AM33XX family of devices with a subclass type
for AM335X device, which is newly added device in the family.
This means, cpu_is_omap34xx(), cpu_is_am33xx() and cpu_is_am335x()
checks will return success on AM335X device.
A kernel config option CONFIG_SOC_OMAPAM33XX is added under OMAP3
to include support for AM33XX build.
Also, cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence
struct clksel_rate.flags, struct prcm_config.flags and cpu_mask
are changed to u16 from u8.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Hemant Pedanekar <hemantp@ti.com>
---
arch/arm/mach-omap2/Kconfig | 5 +++++
arch/arm/mach-omap2/clock.c | 2 +-
arch/arm/mach-omap2/clock.h | 2 +-
arch/arm/mach-omap2/opp2xxx.h | 2 +-
arch/arm/plat-omap/include/plat/clkdev_omap.h | 1 +
arch/arm/plat-omap/include/plat/clock.h | 3 ++-
arch/arm/plat-omap/include/plat/cpu.h | 25 +++++++++++++++++++++++++
7 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 57b66d5..12ab835 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -78,6 +78,11 @@ config SOC_OMAPTI816X
depends on ARCH_OMAP3
default y
+config SOC_OMAPAM33XX
+ bool "AM33XX support"
+ depends on ARCH_OMAP3
+ default y
+
config OMAP_PACKAGE_ZAF
bool
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 1f3481f..f57ed5b 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -35,7 +35,7 @@
#include "cm-regbits-24xx.h"
#include "cm-regbits-34xx.h"
-u8 cpu_mask;
+u16 cpu_mask;
/*
* clkdm_control: if true, then when a clock is enabled in the
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 48ac568..687d3d3 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -130,7 +130,7 @@ void omap2_clk_print_new_rates(const char *hfclkin_ck_name,
const char *core_ck_name,
const char *mpu_ck_name);
-extern u8 cpu_mask;
+extern u16 cpu_mask;
extern const struct clkops clkops_omap2_dflt_wait;
extern const struct clkops clkops_dummy;
diff --git a/arch/arm/mach-omap2/opp2xxx.h b/arch/arm/mach-omap2/opp2xxx.h
index 8affc66..8fae534 100644
--- a/arch/arm/mach-omap2/opp2xxx.h
+++ b/arch/arm/mach-omap2/opp2xxx.h
@@ -51,7 +51,7 @@ struct prcm_config {
unsigned long cm_clksel2_pll; /* dpllx1 or x2 out */
unsigned long cm_clksel_mdm; /* modem dividers 2430 only */
unsigned long base_sdrc_rfr; /* base refresh timing for a set */
- unsigned char flags;
+ unsigned short flags;
};
diff --git a/arch/arm/plat-omap/include/plat/clkdev_omap.h b/arch/arm/plat-omap/include/plat/clkdev_omap.h
index 387a963..6d84c0c 100644
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -40,6 +40,7 @@ struct omap_clk {
#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_34XX (CK_3430ES1 | CK_3430ES2PLUS)
diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
index 197ca03..168c54e 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -59,6 +59,7 @@ struct clkops {
#define RATE_IN_4430 (1 << 5)
#define RATE_IN_TI816X (1 << 6)
#define RATE_IN_4460 (1 << 7)
+#define RATE_IN_AM33XX (1 << 8)
#define RATE_IN_24XX (RATE_IN_242X | RATE_IN_243X)
#define RATE_IN_34XX (RATE_IN_3430ES1 | RATE_IN_3430ES2PLUS)
@@ -84,7 +85,7 @@ struct clkops {
struct clksel_rate {
u32 val;
u8 div;
- u8 flags;
+ u16 flags;
};
/**
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
index 2f90269..9f4d5c3 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -78,6 +78,14 @@ static inline int is_omap ##class (void) \
return (GET_OMAP_CLASS == (id)) ? 1 : 0; \
}
+#define GET_AM_CLASS ((omap_rev() >> 24) & 0xff)
+
+#define IS_AM_CLASS(class, id) \
+static inline int is_am ##class (void) \
+{ \
+ return (GET_AM_CLASS == (id)) ? 1 : 0; \
+}
+
#define GET_OMAP_SUBCLASS ((omap_rev() >> 20) & 0x0fff)
#define IS_OMAP_SUBCLASS(subclass, id) \
@@ -92,12 +100,19 @@ static inline int is_ti ##subclass (void) \
return (GET_OMAP_SUBCLASS == (id)) ? 1 : 0; \
}
+#define IS_AM_SUBCLASS(subclass, id) \
+static inline int is_am ##subclass (void) \
+{ \
+ return (GET_OMAP_SUBCLASS == (id)) ? 1 : 0; \
+}
+
IS_OMAP_CLASS(7xx, 0x07)
IS_OMAP_CLASS(15xx, 0x15)
IS_OMAP_CLASS(16xx, 0x16)
IS_OMAP_CLASS(24xx, 0x24)
IS_OMAP_CLASS(34xx, 0x34)
IS_OMAP_CLASS(44xx, 0x44)
+IS_AM_CLASS(33xx, 0x33)
IS_OMAP_SUBCLASS(242x, 0x242)
IS_OMAP_SUBCLASS(243x, 0x243)
@@ -107,6 +122,7 @@ IS_OMAP_SUBCLASS(443x, 0x443)
IS_OMAP_SUBCLASS(446x, 0x446)
IS_TI_SUBCLASS(816x, 0x816)
+IS_AM_SUBCLASS(335x, 0x335)
#define cpu_is_omap7xx() 0
#define cpu_is_omap15xx() 0
@@ -117,6 +133,8 @@ IS_TI_SUBCLASS(816x, 0x816)
#define cpu_is_omap34xx() 0
#define cpu_is_omap343x() 0
#define cpu_is_ti816x() 0
+#define cpu_is_am33xx() 0
+#define cpu_is_am335x() 0
#define cpu_is_omap44xx() 0
#define cpu_is_omap443x() 0
#define cpu_is_omap446x() 0
@@ -323,6 +341,8 @@ IS_OMAP_TYPE(3517, 0x3517)
# undef cpu_is_omap3505
# undef cpu_is_omap3517
# undef cpu_is_ti816x
+# undef cpu_is_am33xx
+# undef cpu_is_am335x
# define cpu_is_omap3430() is_omap3430()
# define cpu_is_omap3503() (cpu_is_omap3430() && \
(!omap3_has_iva()) && \
@@ -340,6 +360,8 @@ IS_OMAP_TYPE(3517, 0x3517)
# undef cpu_is_omap3630
# define cpu_is_omap3630() is_omap363x()
# define cpu_is_ti816x() is_ti816x()
+# define cpu_is_am33xx() is_am33xx()
+# define cpu_is_am335x() is_am335x()
#endif
# if defined(CONFIG_ARCH_OMAP4)
@@ -386,6 +408,9 @@ IS_OMAP_TYPE(3517, 0x3517)
#define TI8168_REV_ES1_0 TI816X_CLASS
#define TI8168_REV_ES1_1 (TI816X_CLASS | (0x1 << 8))
+#define AM335X_CLASS 0x33500034
+#define AM335X_REV_ES1_0 AM335X_CLASS
+
#define OMAP443X_CLASS 0x44300044
#define OMAP4430_REV_ES1_0 (OMAP443X_CLASS | (0x10 << 8))
#define OMAP4430_REV_ES2_0 (OMAP443X_CLASS | (0x20 << 8))
--
1.7.0.4
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH-V3 1/4] arm:omap:am33xx: Update common omap platform files
2011-09-20 14:32 ` [PATCH-V3 1/4] arm:omap:am33xx: Update common omap platform files hvaibhav at ti.com
@ 2011-10-06 23:03 ` Tony Lindgren
0 siblings, 0 replies; 57+ messages in thread
From: Tony Lindgren @ 2011-10-06 23:03 UTC (permalink / raw)
To: linux-arm-kernel
* hvaibhav at ti.com <hvaibhav@ti.com> [110920 06:59]:
> From: Afzal Mohammed <afzal@ti.com>
>
> This patch updates the common platform files with AM335X device
> support (AM33XX family).
>
> The approach taken in this patch is,
> AM33XX device will be considered as OMAP3 variant, and a separate
> SoC class created for AM33XX family of devices with a subclass type
> for AM335X device, which is newly added device in the family.
>
> This means, cpu_is_omap34xx(), cpu_is_am33xx() and cpu_is_am335x()
> checks will return success on AM335X device.
> A kernel config option CONFIG_SOC_OMAPAM33XX is added under OMAP3
> to include support for AM33XX build.
>
> Also, cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence
> struct clksel_rate.flags, struct prcm_config.flags and cpu_mask
> are changed to u16 from u8.
>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Cc: Hemant Pedanekar <hemantp@ti.com>
I'll add this one into soc branch.
Regards,
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine specific sources
@ 2011-09-20 14:32 ` hvaibhav at ti.com
2011-09-26 18:45 ` Kevin Hilman
2011-11-05 9:41 ` Hiremath, Vaibhav
0 siblings, 2 replies; 57+ messages in thread
From: hvaibhav at ti.com @ 2011-09-20 14:32 UTC (permalink / raw)
To: linux-arm-kernel
From: Afzal Mohammed <afzal@ti.com>
This patch updates the common machine specific source files for
support for AM33XX/AM335x with cpu type, macros for identification of
AM33XX/AM335X device.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
---
arch/arm/mach-omap2/clock3xxx_data.c | 6 +++++-
arch/arm/mach-omap2/common.c | 16 ++++++++++++++++
arch/arm/mach-omap2/id.c | 10 ++++++++--
arch/arm/mach-omap2/io.c | 25 +++++++++++++++++++++++++
arch/arm/mach-omap2/serial.c | 6 +++---
arch/arm/plat-omap/include/plat/am33xx.h | 25 +++++++++++++++++++++++++
arch/arm/plat-omap/include/plat/common.h | 1 +
arch/arm/plat-omap/include/plat/hardware.h | 1 +
arch/arm/plat-omap/include/plat/io.h | 20 ++++++++++++++++++++
arch/arm/plat-omap/include/plat/omap34xx.h | 2 ++
arch/arm/plat-omap/io.c | 5 +++++
11 files changed, 111 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/am33xx.h
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
index dadb8c6..2ee472c 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3493,6 +3493,9 @@ int __init omap3xxx_clk_init(void)
} else if (cpu_is_ti816x()) {
cpu_mask = RATE_IN_TI816X;
cpu_clkflg = CK_TI816X;
+ } else if (cpu_is_am33xx()) {
+ cpu_mask = RATE_IN_AM33XX;
+ cpu_clkflg = CK_AM33XX;
} else if (cpu_is_omap34xx()) {
if (omap_rev() == OMAP3430_REV_ES1_0) {
cpu_mask = RATE_IN_3430ES1;
@@ -3576,7 +3579,8 @@ int __init omap3xxx_clk_init(void)
* Lock DPLL5 -- here only until other device init code can
* handle this
*/
- if (!cpu_is_ti816x() && (omap_rev() >= OMAP3430_REV_ES2_0))
+ if (!cpu_is_ti816x() && !cpu_is_am33xx() &&
+ (omap_rev() >= OMAP3430_REV_ES2_0))
omap3_clk_lock_dpll5();
/* Avoid sleeping during omap3_core_dpll_m2_set_rate() */
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 3f20cbb..395a9b6 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -119,6 +119,22 @@ void __init omap2_set_globals_ti816x(void)
{
__omap2_set_globals(&ti816x_globals);
}
+
+#define AM33XX_TAP_BASE (AM33XX_CTRL_BASE + \
+ TI816X_CONTROL_DEVICE_ID - 0x204)
+
+static struct omap_globals am33xx_globals = {
+ .class = OMAP343X_CLASS,
+ .tap = OMAP2_L4_IO_ADDRESS(AM33XX_TAP_BASE),
+ .ctrl = AM33XX_CTRL_BASE,
+ .prm = AM33XX_PRCM_BASE,
+ .cm = AM33XX_PRCM_BASE,
+};
+
+void __init omap2_set_globals_am33xx(void)
+{
+ __omap2_set_globals(&am33xx_globals);
+}
#endif
#if defined(CONFIG_ARCH_OMAP4)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index d27daf9..540b6f1 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -337,6 +337,10 @@ static void __init omap3_check_revision(const char **cpu_rev)
break;
}
break;
+ case 0xb944:
+ omap_revision = AM335X_REV_ES1_0;
+ *cpu_rev = "1.0";
+ break;
default:
/* Unknown default to latest silicon rev as default */
omap_revision = OMAP3630_REV_ES1_2;
@@ -429,6 +433,8 @@ static void __init omap3_cpuinfo(const char *cpu_rev)
cpu_name = (omap3_has_sgx()) ? "AM3517" : "AM3505";
} else if (cpu_is_ti816x()) {
cpu_name = "TI816X";
+ } else if (cpu_is_am335x()) {
+ cpu_name = "AM335X";
} else if (omap3_has_iva() && omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
cpu_name = "OMAP3430/3530";
@@ -469,8 +475,8 @@ void __init omap2_check_revision(void)
} else if (cpu_is_omap34xx()) {
omap3_check_revision(&cpu_rev);
- /* TI816X doesn't have feature register */
- if (!cpu_is_ti816x())
+ /* TI816X/AM335X doesn't have feature register */
+ if (!cpu_is_ti816x() && !cpu_is_am33xx())
omap3_check_features();
else
ti816x_check_features();
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 40b6d47..ccd50de 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -182,7 +182,24 @@ static struct map_desc omapti816x_io_desc[] __initdata = {
.pfn = __phys_to_pfn(L4_34XX_PHYS),
.length = L4_34XX_SIZE,
.type = MT_DEVICE
+ }
+};
+#endif
+
+#ifdef CONFIG_SOC_OMAPAM33XX
+static struct map_desc omapam33xx_io_desc[] __initdata = {
+ {
+ .virtual = L4_34XX_VIRT,
+ .pfn = __phys_to_pfn(L4_34XX_PHYS),
+ .length = L4_34XX_SIZE,
+ .type = MT_DEVICE
},
+ {
+ .virtual = L4_WK_AM33XX_VIRT,
+ .pfn = __phys_to_pfn(L4_WK_AM33XX_PHYS),
+ .length = L4_WK_AM33XX_SIZE,
+ .type = MT_DEVICE
+ }
};
#endif
@@ -286,6 +303,14 @@ void __init omapti816x_map_common_io(void)
}
#endif
+#ifdef CONFIG_SOC_OMAPAM33XX
+void __init omapam33xx_map_common_io(void)
+{
+ iotable_init(omapam33xx_io_desc, ARRAY_SIZE(omapam33xx_io_desc));
+ _omap2_map_common_io();
+}
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
void __init omap44xx_map_common_io(void)
{
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 466fc72..b7782ee 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -486,7 +486,7 @@ static void omap_uart_idle_init(struct omap_uart_state *uart)
mod_timer(&uart->timer, jiffies + uart->timeout);
omap_uart_smart_idle_enable(uart, 0);
- if (cpu_is_omap34xx() && !cpu_is_ti816x()) {
+ if (cpu_is_omap34xx() && !(cpu_is_ti816x() || cpu_is_am33xx())) {
u32 mod = (uart->num > 1) ? OMAP3430_PER_MOD : CORE_MOD;
u32 wk_mask = 0;
u32 padconf = 0;
@@ -768,7 +768,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)
*/
uart->regshift = p->regshift;
uart->membase = p->membase;
- if (cpu_is_omap44xx() || cpu_is_ti816x())
+ if (cpu_is_omap44xx() || cpu_is_ti816x() || cpu_is_am33xx())
uart->errata |= UART_ERRATA_FIFO_FULL_ABORT;
else if ((serial_read_reg(uart, UART_OMAP_MVER) & 0xFF)
>= UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
@@ -851,7 +851,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)
}
/* Enable the MDR1 errata for OMAP3 */
- if (cpu_is_omap34xx() && !cpu_is_ti816x())
+ if (cpu_is_omap34xx() && !(cpu_is_ti816x() || cpu_is_am33xx()))
uart->errata |= UART_ERRATA_i202_MDR1_ACCESS;
}
diff --git a/arch/arm/plat-omap/include/plat/am33xx.h b/arch/arm/plat-omap/include/plat/am33xx.h
new file mode 100644
index 0000000..06c19bb
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/am33xx.h
@@ -0,0 +1,25 @@
+/*
+ * This file contains the address info for various AM33XX modules.
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc. - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ASM_ARCH_AM33XX_H
+#define __ASM_ARCH_AM33XX_H
+
+#define L4_SLOW_AM33XX_BASE 0x48000000
+
+#define AM33XX_SCM_BASE 0x44E10000
+#define AM33XX_CTRL_BASE AM33XX_SCM_BASE
+#define AM33XX_PRCM_BASE 0x44E00000
+
+#endif /* __ASM_ARCH_AM33XX_H */
diff --git a/arch/arm/plat-omap/include/plat/common.h b/arch/arm/plat-omap/include/plat/common.h
index 4564cc6..6827e34 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -67,6 +67,7 @@ void omap2_set_globals_243x(void);
void omap2_set_globals_3xxx(void);
void omap2_set_globals_443x(void);
void omap2_set_globals_ti816x(void);
+void omap2_set_globals_am33xx(void);
/* These get called from omap2_set_globals_xxxx(), do not call these */
void omap2_set_globals_tap(struct omap_globals *);
diff --git a/arch/arm/plat-omap/include/plat/hardware.h b/arch/arm/plat-omap/include/plat/hardware.h
index e87efe1..e6521e1 100644
--- a/arch/arm/plat-omap/include/plat/hardware.h
+++ b/arch/arm/plat-omap/include/plat/hardware.h
@@ -287,5 +287,6 @@
#include <plat/omap34xx.h>
#include <plat/omap44xx.h>
#include <plat/ti816x.h>
+#include <plat/am33xx.h>
#endif /* __ASM_ARCH_OMAP_HARDWARE_H */
diff --git a/arch/arm/plat-omap/include/plat/io.h b/arch/arm/plat-omap/include/plat/io.h
index d72ec85..0c54a00 100644
--- a/arch/arm/plat-omap/include/plat/io.h
+++ b/arch/arm/plat-omap/include/plat/io.h
@@ -73,6 +73,9 @@
#define OMAP4_L3_IO_OFFSET 0xb4000000
#define OMAP4_L3_IO_ADDRESS(pa) IOMEM((pa) + OMAP4_L3_IO_OFFSET) /* L3 */
+#define AM33XX_L4_WK_IO_OFFSET 0xb5000000
+#define AM33XX_L4_WK_IO_ADDRESS(pa) IOMEM((pa) + AM33XX_L4_WK_IO_OFFSET)
+
#define OMAP4_L3_PER_IO_OFFSET 0xb1100000
#define OMAP4_L3_PER_IO_ADDRESS(pa) IOMEM((pa) + OMAP4_L3_PER_IO_OFFSET)
@@ -154,6 +157,15 @@
#define L4_34XX_SIZE SZ_4M /* 1MB of 128MB used, want 1MB sect */
/*
+ * ----------------------------------------------------------------------------
+ * AM33XX specific IO mapping
+ * ----------------------------------------------------------------------------
+ */
+#define L4_WK_AM33XX_PHYS L4_WK_AM33XX_BASE
+#define L4_WK_AM33XX_VIRT (L4_WK_AM33XX_PHYS + AM33XX_L4_WK_IO_OFFSET)
+#define L4_WK_AM33XX_SIZE SZ_4M /* 1MB of 128MB used, want 1MB sect */
+
+/*
* Need to look at the Size 4M for L4.
* VPOM3430 was not working for Int controller
*/
@@ -291,6 +303,14 @@ static inline void omapti816x_map_common_io(void)
}
#endif
+#ifdef CONFIG_SOC_OMAPAM33XX
+extern void omapam33xx_map_common_io(void);
+#else
+static inline void omapam33xx_map_common_io(void)
+{
+}
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
extern void omap44xx_map_common_io(void);
#else
diff --git a/arch/arm/plat-omap/include/plat/omap34xx.h b/arch/arm/plat-omap/include/plat/omap34xx.h
index b9e8588..0d818ac 100644
--- a/arch/arm/plat-omap/include/plat/omap34xx.h
+++ b/arch/arm/plat-omap/include/plat/omap34xx.h
@@ -35,6 +35,8 @@
#define L4_EMU_34XX_BASE 0x54000000
#define L3_34XX_BASE 0x68000000
+#define L4_WK_AM33XX_BASE 0x44C00000
+
#define OMAP3430_32KSYNCT_BASE 0x48320000
#define OMAP3430_CM_BASE 0x48004800
#define OMAP3430_PRM_BASE 0x48306800
diff --git a/arch/arm/plat-omap/io.c b/arch/arm/plat-omap/io.c
index f1ecfa9..25a32b2 100644
--- a/arch/arm/plat-omap/io.c
+++ b/arch/arm/plat-omap/io.c
@@ -88,6 +88,11 @@ void __iomem *omap_ioremap(unsigned long p, size_t size, unsigned int type)
if (cpu_is_ti816x()) {
if (BETWEEN(p, L4_34XX_PHYS, L4_34XX_SIZE))
return XLATE(p, L4_34XX_PHYS, L4_34XX_VIRT);
+ } else if (cpu_is_am33xx()) {
+ if (BETWEEN(p, L4_34XX_PHYS, L4_34XX_SIZE))
+ return XLATE(p, L4_34XX_PHYS, L4_34XX_VIRT);
+ if (BETWEEN(p, L4_WK_AM33XX_PHYS, L4_WK_AM33XX_SIZE))
+ return XLATE(p, L4_WK_AM33XX_PHYS, L4_WK_AM33XX_VIRT);
} else if (cpu_is_omap34xx()) {
if (BETWEEN(p, L3_34XX_PHYS, L3_34XX_SIZE))
return XLATE(p, L3_34XX_PHYS, L3_34XX_VIRT);
--
1.7.0.4
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine specific sources
2011-09-20 14:32 ` [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine specific sources hvaibhav at ti.com
@ 2011-09-26 18:45 ` Kevin Hilman
2011-09-30 12:09 ` Premi, Sanjeev
2011-11-05 9:41 ` Hiremath, Vaibhav
1 sibling, 1 reply; 57+ messages in thread
From: Kevin Hilman @ 2011-09-26 18:45 UTC (permalink / raw)
To: linux-arm-kernel
<hvaibhav@ti.com> writes:
> From: Afzal Mohammed <afzal@ti.com>
>
> This patch updates the common machine specific source files for
> support for AM33XX/AM335x with cpu type, macros for identification of
> AM33XX/AM335X device.
>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
[...]
> @@ -3576,7 +3579,8 @@ int __init omap3xxx_clk_init(void)
> * Lock DPLL5 -- here only until other device init code can
> * handle this
> */
> - if (!cpu_is_ti816x() && (omap_rev() >= OMAP3430_REV_ES2_0))
> + if (!cpu_is_ti816x() && !cpu_is_am33xx() &&
> + (omap_rev() >= OMAP3430_REV_ES2_0))
> omap3_clk_lock_dpll5();
This is getting ugly.
Instead of continuing to expand this if-list, I think it's time for a
new feature-flag for whether or not an SoC has DPLL5 instead.
Kevin
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine specific sources
2011-09-26 18:45 ` Kevin Hilman
@ 2011-09-30 12:09 ` Premi, Sanjeev
2011-09-30 17:09 ` Kevin Hilman
0 siblings, 1 reply; 57+ messages in thread
From: Premi, Sanjeev @ 2011-09-30 12:09 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org
> [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Hilman, Kevin
> Sent: Tuesday, September 27, 2011 12:16 AM
> To: Hiremath, Vaibhav
> Cc: linux-omap at vger.kernel.org; paul at pwsan.com;
> tony at atomide.com; linux-arm-kernel at lists.infradead.org;
> Mohammed, Afzal
> Subject: Re: [PATCH-V3 2/4] arm:omap:am33xx: Update common
> OMAP machine specific sources
>
> <hvaibhav@ti.com> writes:
>
> > From: Afzal Mohammed <afzal@ti.com>
> >
> > This patch updates the common machine specific source files for
> > support for AM33XX/AM335x with cpu type, macros for
> identification of
> > AM33XX/AM335X device.
> >
> > Signed-off-by: Afzal Mohammed <afzal@ti.com>
> > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
>
> [...]
>
> > @@ -3576,7 +3579,8 @@ int __init omap3xxx_clk_init(void)
> > * Lock DPLL5 -- here only until other device init code can
> > * handle this
> > */
> > - if (!cpu_is_ti816x() && (omap_rev() >= OMAP3430_REV_ES2_0))
> > + if (!cpu_is_ti816x() && !cpu_is_am33xx() &&
> > + (omap_rev() >= OMAP3430_REV_ES2_0))
> > omap3_clk_lock_dpll5();
>
> This is getting ugly.
>
> Instead of continuing to expand this if-list, I think it's time for a
> new feature-flag for whether or not an SoC has DPLL5 instead.
I agree that the code is really getting ugly here. But, isn't
feature-flag going to be over-used with this and similar features?
Just thinking ahead, for these possible cases:
1) An soc adds DPLL6.
2) An soc uses DPLL5, but mechanism to lock is different.
Wouldn't it be better to have a scheme like this:
1) Define a simple structure for DPLLs.
2) Initialize the unused DPLLs to be null/ -1 early
in arch/soc specific init.
3) The DPLL functions check for corresponding flag on
entry.
~sanjeev
>
> Kevin
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine specific sources
2011-09-30 12:09 ` Premi, Sanjeev
@ 2011-09-30 17:09 ` Kevin Hilman
2011-10-06 23:03 ` Tony Lindgren
0 siblings, 1 reply; 57+ messages in thread
From: Kevin Hilman @ 2011-09-30 17:09 UTC (permalink / raw)
To: linux-arm-kernel
"Premi, Sanjeev" <premi@ti.com> writes:
>> -----Original Message-----
>> From: linux-omap-owner at vger.kernel.org
>> [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Hilman, Kevin
>> Sent: Tuesday, September 27, 2011 12:16 AM
>> To: Hiremath, Vaibhav
>> Cc: linux-omap at vger.kernel.org; paul at pwsan.com;
>> tony at atomide.com; linux-arm-kernel at lists.infradead.org;
>> Mohammed, Afzal
>> Subject: Re: [PATCH-V3 2/4] arm:omap:am33xx: Update common
>> OMAP machine specific sources
>>
>> <hvaibhav@ti.com> writes:
>>
>> > From: Afzal Mohammed <afzal@ti.com>
>> >
>> > This patch updates the common machine specific source files for
>> > support for AM33XX/AM335x with cpu type, macros for
>> identification of
>> > AM33XX/AM335X device.
>> >
>> > Signed-off-by: Afzal Mohammed <afzal@ti.com>
>> > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
>>
>> [...]
>>
>> > @@ -3576,7 +3579,8 @@ int __init omap3xxx_clk_init(void)
>> > * Lock DPLL5 -- here only until other device init code can
>> > * handle this
>> > */
>> > - if (!cpu_is_ti816x() && (omap_rev() >= OMAP3430_REV_ES2_0))
>> > + if (!cpu_is_ti816x() && !cpu_is_am33xx() &&
>> > + (omap_rev() >= OMAP3430_REV_ES2_0))
>> > omap3_clk_lock_dpll5();
>>
>> This is getting ugly.
>>
>> Instead of continuing to expand this if-list, I think it's time for a
>> new feature-flag for whether or not an SoC has DPLL5 instead.
>
> I agree that the code is really getting ugly here. But, isn't
> feature-flag going to be over-used with this and similar features?
>
> Just thinking ahead, for these possible cases:
> 1) An soc adds DPLL6.
> 2) An soc uses DPLL5, but mechanism to lock is different.
You're right.
> Wouldn't it be better to have a scheme like this:
> 1) Define a simple structure for DPLLs.
> 2) Initialize the unused DPLLs to be null/ -1 early
> in arch/soc specific init.
> 3) The DPLL functions check for corresponding flag on
> entry.
Actually, looking at this closer, I think the infrastructure is already
there to handle this cleanly.
Basically, dpll5 should not even be registered for SoCs where it doesn't
exist. Then, any attempts to use DPLL5 would know it doesn't exist
because the call to clk_get() in omap3_clk_lock_dpll5() would fail.
I think the clock3xxx_data.c needs a bit more cleanup so that only
clocks that exist for a given SoC are registered.
Paul already did a similar cleanup for the powerdomain data files by
creating separate lists for common ones and unique ones. Looks like we
need the same for the clock data.
Patches welcome.
Kevin
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine specific sources
2011-09-30 17:09 ` Kevin Hilman
@ 2011-10-06 23:03 ` Tony Lindgren
2011-11-03 13:48 ` Hiremath, Vaibhav
0 siblings, 1 reply; 57+ messages in thread
From: Tony Lindgren @ 2011-10-06 23:03 UTC (permalink / raw)
To: linux-arm-kernel
* Kevin Hilman <khilman@ti.com> [110930 09:35]:
> "Premi, Sanjeev" <premi@ti.com> writes:
>
> Actually, looking at this closer, I think the infrastructure is already
> there to handle this cleanly.
>
> Basically, dpll5 should not even be registered for SoCs where it doesn't
> exist. Then, any attempts to use DPLL5 would know it doesn't exist
> because the call to clk_get() in omap3_clk_lock_dpll5() would fail.
Yes please use the SoC specific lists, see what we have now queued
up in sram-map-io branch. So using SoC specific map_io + init_early +
set_globals should do the trick.
> I think the clock3xxx_data.c needs a bit more cleanup so that only
> clocks that exist for a given SoC are registered.
>
> Paul already did a similar cleanup for the powerdomain data files by
> creating separate lists for common ones and unique ones. Looks like we
> need the same for the clock data.
Right.
Regards,
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine specific sources
2011-10-06 23:03 ` Tony Lindgren
@ 2011-11-03 13:48 ` Hiremath, Vaibhav
0 siblings, 0 replies; 57+ messages in thread
From: Hiremath, Vaibhav @ 2011-11-03 13:48 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Friday, October 07, 2011 4:33 AM
> To: Hilman, Kevin
> Cc: Premi, Sanjeev; Hiremath, Vaibhav; linux-omap at vger.kernel.org;
> paul at pwsan.com; linux-arm-kernel at lists.infradead.org; Mohammed, Afzal
> Subject: Re: [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine
> specific sources
>
> * Kevin Hilman <khilman@ti.com> [110930 09:35]:
> > "Premi, Sanjeev" <premi@ti.com> writes:
> >
> > Actually, looking at this closer, I think the infrastructure is already
> > there to handle this cleanly.
> >
> > Basically, dpll5 should not even be registered for SoCs where it doesn't
> > exist. Then, any attempts to use DPLL5 would know it doesn't exist
> > because the call to clk_get() in omap3_clk_lock_dpll5() would fail.
>
> Yes please use the SoC specific lists, see what we have now queued
> up in sram-map-io branch. So using SoC specific map_io + init_early +
> set_globals should do the trick.
>
Sorry for delayed response, was on festival vacation...
> > I think the clock3xxx_data.c needs a bit more cleanup so that only
> > clocks that exist for a given SoC are registered.
> >
> > Paul already did a similar cleanup for the powerdomain data files by
> > creating separate lists for common ones and unique ones. Looks like we
> > need the same for the clock data.
>
> Right.
>
I agree that we need to clean clock data, but with the current discussion,
feel it may not be so useful, since the clock tree of the AM335x device is
different than OMAP3 family of devices -
http://www.ti.com/product/am3359
Public TRM -
http://www.ti.com/lit/ug/spruh73/spruh73.pdf
While porting Linux kernel to AM335x EVM, I had created separate clock data
file for AM33xx -
- arch/arm/mach-omap2/clock33xx_data.c
Similar for clock domain data -
- arch/arm/mach-omap2/clockdomains33xx_data.c
So we don't need any of the changes which we are discussing about, since execution doesn't reach there.
Currently looking at clock data, to see how this cleanup can be achieved,
any suggestions/comments/pointers would be helpful.
Thanks,
Vaibhav
> Regards,
>
> Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine specific sources
2011-09-20 14:32 ` [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine specific sources hvaibhav at ti.com
2011-09-26 18:45 ` Kevin Hilman
@ 2011-11-05 9:41 ` Hiremath, Vaibhav
2011-11-05 10:29 ` Hiremath, Vaibhav
1 sibling, 1 reply; 57+ messages in thread
From: Hiremath, Vaibhav @ 2011-11-05 9:41 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Hiremath, Vaibhav
> Sent: Tuesday, September 20, 2011 8:02 PM
> To: linux-omap at vger.kernel.org
> Cc: Hilman, Kevin; paul at pwsan.com; tony at atomide.com; linux-arm-
> kernel at lists.infradead.org; Mohammed, Afzal; Hiremath, Vaibhav
> Subject: [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine
> specific sources
>
> From: Afzal Mohammed <afzal@ti.com>
>
> This patch updates the common machine specific source files for
> support for AM33XX/AM335x with cpu type, macros for identification of
> AM33XX/AM335X device.
>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> ---
> arch/arm/mach-omap2/clock3xxx_data.c | 6 +++++-
> arch/arm/mach-omap2/common.c | 16 ++++++++++++++++
> arch/arm/mach-omap2/id.c | 10 ++++++++--
> arch/arm/mach-omap2/io.c | 25
> +++++++++++++++++++++++++
> arch/arm/mach-omap2/serial.c | 6 +++---
> arch/arm/plat-omap/include/plat/am33xx.h | 25
> +++++++++++++++++++++++++
> arch/arm/plat-omap/include/plat/common.h | 1 +
> arch/arm/plat-omap/include/plat/hardware.h | 1 +
> arch/arm/plat-omap/include/plat/io.h | 20 ++++++++++++++++++++
> arch/arm/plat-omap/include/plat/omap34xx.h | 2 ++
> arch/arm/plat-omap/io.c | 5 +++++
> 11 files changed, 111 insertions(+), 6 deletions(-)
> create mode 100644 arch/arm/plat-omap/include/plat/am33xx.h
>
> diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-
> omap2/clock3xxx_data.c
> index dadb8c6..2ee472c 100644
> --- a/arch/arm/mach-omap2/clock3xxx_data.c
> +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> @@ -3493,6 +3493,9 @@ int __init omap3xxx_clk_init(void)
> } else if (cpu_is_ti816x()) {
> cpu_mask = RATE_IN_TI816X;
> cpu_clkflg = CK_TI816X;
> + } else if (cpu_is_am33xx()) {
> + cpu_mask = RATE_IN_AM33XX;
> + cpu_clkflg = CK_AM33XX;
> } else if (cpu_is_omap34xx()) {
> if (omap_rev() == OMAP3430_REV_ES1_0) {
> cpu_mask = RATE_IN_3430ES1;
> @@ -3576,7 +3579,8 @@ int __init omap3xxx_clk_init(void)
> * Lock DPLL5 -- here only until other device init code can
> * handle this
> */
> - if (!cpu_is_ti816x() && (omap_rev() >= OMAP3430_REV_ES2_0))
> + if (!cpu_is_ti816x() && !cpu_is_am33xx() &&
> + (omap_rev() >= OMAP3430_REV_ES2_0))
> omap3_clk_lock_dpll5();
>
> /* Avoid sleeping during omap3_core_dpll_m2_set_rate() */
> diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
> index 3f20cbb..395a9b6 100644
> --- a/arch/arm/mach-omap2/common.c
> +++ b/arch/arm/mach-omap2/common.c
> @@ -119,6 +119,22 @@ void __init omap2_set_globals_ti816x(void)
> {
> __omap2_set_globals(&ti816x_globals);
> }
> +
> +#define AM33XX_TAP_BASE (AM33XX_CTRL_BASE + \
> + TI816X_CONTROL_DEVICE_ID - 0x204)
> +
> +static struct omap_globals am33xx_globals = {
> + .class = OMAP343X_CLASS,
> + .tap = OMAP2_L4_IO_ADDRESS(AM33XX_TAP_BASE),
> + .ctrl = AM33XX_CTRL_BASE,
> + .prm = AM33XX_PRCM_BASE,
> + .cm = AM33XX_PRCM_BASE,
> +};
> +
> +void __init omap2_set_globals_am33xx(void)
> +{
> + __omap2_set_globals(&am33xx_globals);
> +}
> #endif
>
> #if defined(CONFIG_ARCH_OMAP4)
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index d27daf9..540b6f1 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -337,6 +337,10 @@ static void __init omap3_check_revision(const char
> **cpu_rev)
> break;
> }
> break;
> + case 0xb944:
> + omap_revision = AM335X_REV_ES1_0;
> + *cpu_rev = "1.0";
> + break;
> default:
> /* Unknown default to latest silicon rev as default */
> omap_revision = OMAP3630_REV_ES1_2;
> @@ -429,6 +433,8 @@ static void __init omap3_cpuinfo(const char *cpu_rev)
> cpu_name = (omap3_has_sgx()) ? "AM3517" : "AM3505";
> } else if (cpu_is_ti816x()) {
> cpu_name = "TI816X";
> + } else if (cpu_is_am335x()) {
> + cpu_name = "AM335X";
> } else if (omap3_has_iva() && omap3_has_sgx()) {
> /* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
> cpu_name = "OMAP3430/3530";
> @@ -469,8 +475,8 @@ void __init omap2_check_revision(void)
> } else if (cpu_is_omap34xx()) {
> omap3_check_revision(&cpu_rev);
>
> - /* TI816X doesn't have feature register */
> - if (!cpu_is_ti816x())
> + /* TI816X/AM335X doesn't have feature register */
> + if (!cpu_is_ti816x() && !cpu_is_am33xx())
> omap3_check_features();
> else
> ti816x_check_features();
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index 40b6d47..ccd50de 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -182,7 +182,24 @@ static struct map_desc omapti816x_io_desc[]
> __initdata = {
> .pfn = __phys_to_pfn(L4_34XX_PHYS),
> .length = L4_34XX_SIZE,
> .type = MT_DEVICE
> + }
> +};
> +#endif
> +
> +#ifdef CONFIG_SOC_OMAPAM33XX
> +static struct map_desc omapam33xx_io_desc[] __initdata = {
> + {
> + .virtual = L4_34XX_VIRT,
> + .pfn = __phys_to_pfn(L4_34XX_PHYS),
> + .length = L4_34XX_SIZE,
> + .type = MT_DEVICE
> },
> + {
> + .virtual = L4_WK_AM33XX_VIRT,
> + .pfn = __phys_to_pfn(L4_WK_AM33XX_PHYS),
> + .length = L4_WK_AM33XX_SIZE,
> + .type = MT_DEVICE
> + }
> };
> #endif
>
> @@ -286,6 +303,14 @@ void __init omapti816x_map_common_io(void)
> }
> #endif
>
> +#ifdef CONFIG_SOC_OMAPAM33XX
> +void __init omapam33xx_map_common_io(void)
> +{
> + iotable_init(omapam33xx_io_desc, ARRAY_SIZE(omapam33xx_io_desc));
> + _omap2_map_common_io();
> +}
> +#endif
> +
> #ifdef CONFIG_ARCH_OMAP4
> void __init omap44xx_map_common_io(void)
> {
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 466fc72..b7782ee 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -486,7 +486,7 @@ static void omap_uart_idle_init(struct omap_uart_state
> *uart)
> mod_timer(&uart->timer, jiffies + uart->timeout);
> omap_uart_smart_idle_enable(uart, 0);
>
> - if (cpu_is_omap34xx() && !cpu_is_ti816x()) {
> + if (cpu_is_omap34xx() && !(cpu_is_ti816x() || cpu_is_am33xx())) {
> u32 mod = (uart->num > 1) ? OMAP3430_PER_MOD : CORE_MOD;
> u32 wk_mask = 0;
> u32 padconf = 0;
> @@ -768,7 +768,7 @@ void __init omap_serial_init_port(struct
> omap_board_data *bdata)
> */
> uart->regshift = p->regshift;
> uart->membase = p->membase;
> - if (cpu_is_omap44xx() || cpu_is_ti816x())
> + if (cpu_is_omap44xx() || cpu_is_ti816x() || cpu_is_am33xx())
> uart->errata |= UART_ERRATA_FIFO_FULL_ABORT;
> else if ((serial_read_reg(uart, UART_OMAP_MVER) & 0xFF)
> >= UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
> @@ -851,7 +851,7 @@ void __init omap_serial_init_port(struct
> omap_board_data *bdata)
> }
Can I get rid of this if condition as well here with below change -
- * omap44xx, ti816x: Never read empty UART fifo
+ * all >omap3 family of devices: Never read empty UART fifo
* omap3xxx: Never read empty UART fifo on UARTs
* with IP rev >=0x52
*/
uart->regshift = p->regshift;
uart->membase = p->membase;
- if (cpu_is_omap44xx() || cpu_is_ti816x() || cpu_is_am33xx())
- uart->errata |= UART_ERRATA_FIFO_FULL_ABORT;
- else if ((serial_read_reg(uart, UART_OMAP_MVER) & 0xFF)
- >= UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+
+ if ((serial_read_reg(uart, UART_OMAP_MVER) & 0xFF)
+ < UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+ uart->errata &= ~UART_ERRATA_FIFO_FULL_ABORT;
+ else
uart->errata |= UART_ERRATA_FIFO_FULL_ABORT;
if (uart->errata & UART_ERRATA_FIFO_FULL_ABORT) {
Thanks,
Vaibhav
>
> /* Enable the MDR1 errata for OMAP3 */
> - if (cpu_is_omap34xx() && !cpu_is_ti816x())
> + if (cpu_is_omap34xx() && !(cpu_is_ti816x() || cpu_is_am33xx()))
> uart->errata |= UART_ERRATA_i202_MDR1_ACCESS;
> }
>
> diff --git a/arch/arm/plat-omap/include/plat/am33xx.h b/arch/arm/plat-
> omap/include/plat/am33xx.h
> new file mode 100644
> index 0000000..06c19bb
> --- /dev/null
> +++ b/arch/arm/plat-omap/include/plat/am33xx.h
> @@ -0,0 +1,25 @@
> +/*
> + * This file contains the address info for various AM33XX modules.
> + *
> + * Copyright (C) 2011 Texas Instruments, Inc. - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __ASM_ARCH_AM33XX_H
> +#define __ASM_ARCH_AM33XX_H
> +
> +#define L4_SLOW_AM33XX_BASE 0x48000000
> +
> +#define AM33XX_SCM_BASE 0x44E10000
> +#define AM33XX_CTRL_BASE AM33XX_SCM_BASE
> +#define AM33XX_PRCM_BASE 0x44E00000
> +
> +#endif /* __ASM_ARCH_AM33XX_H */
> diff --git a/arch/arm/plat-omap/include/plat/common.h b/arch/arm/plat-
> omap/include/plat/common.h
> index 4564cc6..6827e34 100644
> --- a/arch/arm/plat-omap/include/plat/common.h
> +++ b/arch/arm/plat-omap/include/plat/common.h
> @@ -67,6 +67,7 @@ void omap2_set_globals_243x(void);
> void omap2_set_globals_3xxx(void);
> void omap2_set_globals_443x(void);
> void omap2_set_globals_ti816x(void);
> +void omap2_set_globals_am33xx(void);
>
> /* These get called from omap2_set_globals_xxxx(), do not call these */
> void omap2_set_globals_tap(struct omap_globals *);
> diff --git a/arch/arm/plat-omap/include/plat/hardware.h b/arch/arm/plat-
> omap/include/plat/hardware.h
> index e87efe1..e6521e1 100644
> --- a/arch/arm/plat-omap/include/plat/hardware.h
> +++ b/arch/arm/plat-omap/include/plat/hardware.h
> @@ -287,5 +287,6 @@
> #include <plat/omap34xx.h>
> #include <plat/omap44xx.h>
> #include <plat/ti816x.h>
> +#include <plat/am33xx.h>
>
> #endif /* __ASM_ARCH_OMAP_HARDWARE_H */
> diff --git a/arch/arm/plat-omap/include/plat/io.h b/arch/arm/plat-
> omap/include/plat/io.h
> index d72ec85..0c54a00 100644
> --- a/arch/arm/plat-omap/include/plat/io.h
> +++ b/arch/arm/plat-omap/include/plat/io.h
> @@ -73,6 +73,9 @@
> #define OMAP4_L3_IO_OFFSET 0xb4000000
> #define OMAP4_L3_IO_ADDRESS(pa) IOMEM((pa) + OMAP4_L3_IO_OFFSET) /* L3
> */
>
> +#define AM33XX_L4_WK_IO_OFFSET 0xb5000000
> +#define AM33XX_L4_WK_IO_ADDRESS(pa) IOMEM((pa) +
> AM33XX_L4_WK_IO_OFFSET)
> +
> #define OMAP4_L3_PER_IO_OFFSET 0xb1100000
> #define OMAP4_L3_PER_IO_ADDRESS(pa) IOMEM((pa) +
> OMAP4_L3_PER_IO_OFFSET)
>
> @@ -154,6 +157,15 @@
> #define L4_34XX_SIZE SZ_4M /* 1MB of 128MB used, want 1MB sect
> */
>
> /*
> + * ----------------------------------------------------------------------
> ------
> + * AM33XX specific IO mapping
> + * ----------------------------------------------------------------------
> ------
> + */
> +#define L4_WK_AM33XX_PHYS L4_WK_AM33XX_BASE
> +#define L4_WK_AM33XX_VIRT (L4_WK_AM33XX_PHYS +
> AM33XX_L4_WK_IO_OFFSET)
> +#define L4_WK_AM33XX_SIZE SZ_4M /* 1MB of 128MB used, want 1MB
> sect */
> +
> +/*
> * Need to look at the Size 4M for L4.
> * VPOM3430 was not working for Int controller
> */
> @@ -291,6 +303,14 @@ static inline void omapti816x_map_common_io(void)
> }
> #endif
>
> +#ifdef CONFIG_SOC_OMAPAM33XX
> +extern void omapam33xx_map_common_io(void);
> +#else
> +static inline void omapam33xx_map_common_io(void)
> +{
> +}
> +#endif
> +
> #ifdef CONFIG_ARCH_OMAP4
> extern void omap44xx_map_common_io(void);
> #else
> diff --git a/arch/arm/plat-omap/include/plat/omap34xx.h b/arch/arm/plat-
> omap/include/plat/omap34xx.h
> index b9e8588..0d818ac 100644
> --- a/arch/arm/plat-omap/include/plat/omap34xx.h
> +++ b/arch/arm/plat-omap/include/plat/omap34xx.h
> @@ -35,6 +35,8 @@
> #define L4_EMU_34XX_BASE 0x54000000
> #define L3_34XX_BASE 0x68000000
>
> +#define L4_WK_AM33XX_BASE 0x44C00000
> +
> #define OMAP3430_32KSYNCT_BASE 0x48320000
> #define OMAP3430_CM_BASE 0x48004800
> #define OMAP3430_PRM_BASE 0x48306800
> diff --git a/arch/arm/plat-omap/io.c b/arch/arm/plat-omap/io.c
> index f1ecfa9..25a32b2 100644
> --- a/arch/arm/plat-omap/io.c
> +++ b/arch/arm/plat-omap/io.c
> @@ -88,6 +88,11 @@ void __iomem *omap_ioremap(unsigned long p, size_t size,
> unsigned int type)
> if (cpu_is_ti816x()) {
> if (BETWEEN(p, L4_34XX_PHYS, L4_34XX_SIZE))
> return XLATE(p, L4_34XX_PHYS, L4_34XX_VIRT);
> + } else if (cpu_is_am33xx()) {
> + if (BETWEEN(p, L4_34XX_PHYS, L4_34XX_SIZE))
> + return XLATE(p, L4_34XX_PHYS, L4_34XX_VIRT);
> + if (BETWEEN(p, L4_WK_AM33XX_PHYS, L4_WK_AM33XX_SIZE))
> + return XLATE(p, L4_WK_AM33XX_PHYS, L4_WK_AM33XX_VIRT);
> } else if (cpu_is_omap34xx()) {
> if (BETWEEN(p, L3_34XX_PHYS, L3_34XX_SIZE))
> return XLATE(p, L3_34XX_PHYS, L3_34XX_VIRT);
> --
> 1.7.0.4
^ permalink raw reply [flat|nested] 57+ messages in thread* [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine specific sources
2011-11-05 9:41 ` Hiremath, Vaibhav
@ 2011-11-05 10:29 ` Hiremath, Vaibhav
0 siblings, 0 replies; 57+ messages in thread
From: Hiremath, Vaibhav @ 2011-11-05 10:29 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Hiremath, Vaibhav
> Sent: Saturday, November 05, 2011 3:11 PM
> To: Hiremath, Vaibhav; linux-omap at vger.kernel.org
> Cc: Hilman, Kevin; paul at pwsan.com; tony at atomide.com; linux-arm-
> kernel at lists.infradead.org; Mohammed, Afzal
> Subject: RE: [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine
> specific sources
>
> > -----Original Message-----
> > From: Hiremath, Vaibhav
> > Sent: Tuesday, September 20, 2011 8:02 PM
> > To: linux-omap at vger.kernel.org
> > Cc: Hilman, Kevin; paul at pwsan.com; tony at atomide.com; linux-arm-
> > kernel at lists.infradead.org; Mohammed, Afzal; Hiremath, Vaibhav
> > Subject: [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine
> > specific sources
> >
> > From: Afzal Mohammed <afzal@ti.com>
> >
> > This patch updates the common machine specific source files for
> > support for AM33XX/AM335x with cpu type, macros for identification of
> > AM33XX/AM335X device.
> >
> > Signed-off-by: Afzal Mohammed <afzal@ti.com>
> > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > ---
> > arch/arm/mach-omap2/clock3xxx_data.c | 6 +++++-
> > arch/arm/mach-omap2/common.c | 16 ++++++++++++++++
> > arch/arm/mach-omap2/id.c | 10 ++++++++--
> > arch/arm/mach-omap2/io.c | 25
> > +++++++++++++++++++++++++
> > arch/arm/mach-omap2/serial.c | 6 +++---
> > arch/arm/plat-omap/include/plat/am33xx.h | 25
> > +++++++++++++++++++++++++
> > arch/arm/plat-omap/include/plat/common.h | 1 +
> > arch/arm/plat-omap/include/plat/hardware.h | 1 +
> > arch/arm/plat-omap/include/plat/io.h | 20 ++++++++++++++++++++
> > arch/arm/plat-omap/include/plat/omap34xx.h | 2 ++
> > arch/arm/plat-omap/io.c | 5 +++++
> > 11 files changed, 111 insertions(+), 6 deletions(-)
> > create mode 100644 arch/arm/plat-omap/include/plat/am33xx.h
> >
<snip>
> > diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> > index 466fc72..b7782ee 100644
> > --- a/arch/arm/mach-omap2/serial.c
> > +++ b/arch/arm/mach-omap2/serial.c
> > @@ -486,7 +486,7 @@ static void omap_uart_idle_init(struct
> omap_uart_state
> > *uart)
> > mod_timer(&uart->timer, jiffies + uart->timeout);
> > omap_uart_smart_idle_enable(uart, 0);
> >
> > - if (cpu_is_omap34xx() && !cpu_is_ti816x()) {
> > + if (cpu_is_omap34xx() && !(cpu_is_ti816x() || cpu_is_am33xx())) {
> > u32 mod = (uart->num > 1) ? OMAP3430_PER_MOD : CORE_MOD;
> > u32 wk_mask = 0;
> > u32 padconf = 0;
> > @@ -768,7 +768,7 @@ void __init omap_serial_init_port(struct
> > omap_board_data *bdata)
> > */
> > uart->regshift = p->regshift;
> > uart->membase = p->membase;
> > - if (cpu_is_omap44xx() || cpu_is_ti816x())
> > + if (cpu_is_omap44xx() || cpu_is_ti816x() || cpu_is_am33xx())
> > uart->errata |= UART_ERRATA_FIFO_FULL_ABORT;
> > else if ((serial_read_reg(uart, UART_OMAP_MVER) & 0xFF)
> > >= UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
> > @@ -851,7 +851,7 @@ void __init omap_serial_init_port(struct
> > omap_board_data *bdata)
> > }
>
> Can I get rid of this if condition as well here with below change -
>
> - * omap44xx, ti816x: Never read empty UART fifo
> + * all >omap3 family of devices: Never read empty UART fifo
> * omap3xxx: Never read empty UART fifo on UARTs
> * with IP rev >=0x52
> */
> uart->regshift = p->regshift;
> uart->membase = p->membase;
> - if (cpu_is_omap44xx() || cpu_is_ti816x() || cpu_is_am33xx())
> - uart->errata |= UART_ERRATA_FIFO_FULL_ABORT;
> - else if ((serial_read_reg(uart, UART_OMAP_MVER) & 0xFF)
> - >= UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
> +
> + if ((serial_read_reg(uart, UART_OMAP_MVER) & 0xFF)
> + < UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
> + uart->errata &= ~UART_ERRATA_FIFO_FULL_ABORT;
> + else
> uart->errata |= UART_ERRATA_FIFO_FULL_ABORT;
>
> if (uart->errata & UART_ERRATA_FIFO_FULL_ABORT) {
>
Hit send button bit early, realized that, on all other devices (like AM33xx) the rev id is not incremental order, it has been reseted again, sp right condition here would be -
- if (cpu_is_omap44xx() || cpu_is_ti816x() || cpu_is_am33xx())
- uart->errata |= UART_ERRATA_FIFO_FULL_ABORT;
- else if ((serial_read_reg(uart, UART_OMAP_MVER) & 0xFF)
- >= UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+
+ if (cpu_is_omap34xx() && (serial_read_reg(uart, UART_OMAP_MVER) & 0xFF)
+ < UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+ uart->errata &= ~UART_ERRATA_FIFO_FULL_ABORT;
+ else
uart->errata |= UART_ERRATA_FIFO_FULL_ABORT;
Thanks,
Vaibhav
>
> Thanks,
> Vaibhav
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V3 3/4] arm:omap:am33xx: Create board support and enable build for AM335XEVM
@ 2011-09-20 14:32 ` hvaibhav at ti.com
2011-10-06 23:07 ` Tony Lindgren
0 siblings, 1 reply; 57+ messages in thread
From: hvaibhav at ti.com @ 2011-09-20 14:32 UTC (permalink / raw)
To: linux-arm-kernel
From: Afzal Mohammed <afzal@ti.com>
This patch adds minimal support and build configuration for
AM335X EVM.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
---
arch/arm/mach-omap2/Kconfig | 5 +++
arch/arm/mach-omap2/Makefile | 2 +
arch/arm/mach-omap2/board-am335xevm.c | 57 +++++++++++++++++++++++++++++++++
3 files changed, 64 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-am335xevm.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 12ab835..8533008 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -315,6 +315,11 @@ config MACH_TI8168EVM
depends on SOC_OMAPTI816X
default y
+config MACH_AM335XEVM
+ bool "AM335X Evaluation Module"
+ depends on SOC_OMAPAM33XX
+ default y
+
config MACH_OMAP_4430SDP
bool "OMAP 4430 SDP board"
default y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5a6fe73..47d8de1 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -259,6 +259,8 @@ obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o \
hsmmc.o
obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o
+obj-$(CONFIG_MACH_AM335XEVM) += board-am335xevm.o
+
# Platform specific device init code
usbfs-$(CONFIG_ARCH_OMAP_OTG) := usb-fs.o
obj-y += $(usbfs-m) $(usbfs-y)
diff --git a/arch/arm/mach-omap2/board-am335xevm.c b/arch/arm/mach-omap2/board-am335xevm.c
new file mode 100644
index 0000000..afa3f26
--- /dev/null
+++ b/arch/arm/mach-omap2/board-am335xevm.c
@@ -0,0 +1,57 @@
+/*
+ * Code for AM335X EVM.
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc. - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+
+#include <mach/hardware.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+
+#include <plat/irqs.h>
+#include <plat/board.h>
+#include <plat/common.h>
+
+static struct omap_board_config_kernel am335x_evm_config[] __initdata = {
+};
+
+static void __init am335x_init_early(void)
+{
+ omap2_init_common_infrastructure();
+ omap2_init_common_devices(NULL, NULL);
+}
+
+static void __init am335x_evm_init(void)
+{
+ omap_serial_init();
+ omap_board_config = am335x_evm_config;
+ omap_board_config_size = ARRAY_SIZE(am335x_evm_config);
+}
+
+static void __init am335x_evm_map_io(void)
+{
+ omap2_set_globals_am33xx();
+ omapam33xx_map_common_io();
+}
+
+MACHINE_START(AM335XEVM, "am335xevm")
+ /* Maintainer: Texas Instruments */
+ .boot_params = 0x80000100,
+ .map_io = am335x_evm_map_io,
+ .init_early = am335x_init_early,
+ .init_irq = ti816x_init_irq,
+ .timer = &omap3_timer,
+ .init_machine = am335x_evm_init,
+MACHINE_END
--
1.7.0.4
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH-V3 3/4] arm:omap:am33xx: Create board support and enable build for AM335XEVM
2011-09-20 14:32 ` [PATCH-V3 3/4] arm:omap:am33xx: Create board support and enable build for AM335XEVM hvaibhav at ti.com
@ 2011-10-06 23:07 ` Tony Lindgren
0 siblings, 0 replies; 57+ messages in thread
From: Tony Lindgren @ 2011-10-06 23:07 UTC (permalink / raw)
To: linux-arm-kernel
* hvaibhav at ti.com <hvaibhav@ti.com> [110920 06:59]:
> From: Afzal Mohammed <afzal@ti.com>
>
> This patch adds minimal support and build configuration for
> AM335X EVM.
...
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-am335xevm.c
> +
> +MACHINE_START(AM335XEVM, "am335xevm")
> + /* Maintainer: Texas Instruments */
> + .boot_params = 0x80000100,
> + .map_io = am335x_evm_map_io,
> + .init_early = am335x_init_early,
> + .init_irq = ti816x_init_irq,
> + .timer = &omap3_timer,
> + .init_machine = am335x_evm_init,
> +MACHINE_END
Please just add the support into board-am3517evm.c, the board-*.c
files will be going away with device tree.
Regards,
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging support
@ 2011-09-20 14:32 ` hvaibhav at ti.com
2011-10-06 23:09 ` Tony Lindgren
0 siblings, 1 reply; 57+ messages in thread
From: hvaibhav at ti.com @ 2011-09-20 14:32 UTC (permalink / raw)
To: linux-arm-kernel
From: Afzal Mohammed <afzal@ti.com>
Add support for low level debugging on AM335X EVM (AM33XX family).
Currently only support for UART1 console, which is used on AM335X EVM
is added.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
---
arch/arm/mach-omap2/include/mach/debug-macro.S | 22 ++++++++++++++++++++++
arch/arm/plat-omap/include/plat/serial.h | 4 ++++
arch/arm/plat-omap/include/plat/uncompress.h | 6 ++++++
3 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S b/arch/arm/mach-omap2/include/mach/debug-macro.S
index 48adfe9..f649973 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -78,6 +78,8 @@ omap_uart_lsr: .word 0
beq 82f @ configure UART2
cmp \rp, #TI816XUART3 @ ti816x UART offsets different
beq 83f @ configure UART3
+ cmp \rp, #AM33XXUART1 @ AM33XX UART offsets different
+ beq 84f @ configure UART1
cmp \rp, #ZOOM_UART @ only on zoom2/3
beq 95f @ configure ZOOM_UART
@@ -106,6 +108,9 @@ omap_uart_lsr: .word 0
b 98f
83: mov \rp, #UART_OFFSET(TI816X_UART3_BASE)
b 98f
+84: ldr \rp, =AM33XX_UART1_BASE
+ and \rp, \rp, #0x00ffffff
+ b 97f
95: ldr \rp, =ZOOM_UART_BASE
mrc p15, 0, \rv, c1, c0
tst \rv, #1 @ MMU enabled?
@@ -121,6 +126,23 @@ omap_uart_lsr: .word 0
b 10b
/* Store both phys and virt address for the uart */
+97: add \rp, \rp, #0x44000000 @ phys base
+ mrc p15, 0, \rv, c1, c0
+ tst \rv, #1 @ MMU enabled?
+ ldreq \rv, =omap_uart_v2p(omap_uart_phys) @ MMU disabled
+ ldrne \rv, =omap_uart_phys @ MMU enabled
+ str \rp, [\rv, #0]
+ sub \rp, \rp, #0x44000000 @ phys base
+ add \rp, \rp, #0xf9000000 @ virt base
+ add \rv, \rv, #4 @ omap_uart_virt
+ str \rp, [\rv, #0]
+ mov \rp, #(UART_LSR << OMAP_PORT_SHIFT)
+ add \rv, \rv, #4 @ omap_uart_lsr
+ str \rp, [\rv, #0]
+
+ b 10b
+
+ /* Store both phys and virt address for the uart */
98: add \rp, \rp, #0x48000000 @ phys base
mrc p15, 0, \rv, c1, c0
tst \rv, #1 @ MMU enabled?
diff --git a/arch/arm/plat-omap/include/plat/serial.h b/arch/arm/plat-omap/include/plat/serial.h
index de3b10c..ad19377 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -59,6 +59,9 @@
/* AM3505/3517 UART4 */
#define AM35XX_UART4_BASE 0x4809E000 /* Only on AM3505/3517 */
+/* AM33XX serial port */
+#define AM33XX_UART1_BASE 0x44E09000
+
/* External port on Zoom2/3 */
#define ZOOM_UART_BASE 0x10000000
#define ZOOM_UART_VIRT 0xfa400000
@@ -92,6 +95,7 @@
#define TI816XUART1 81
#define TI816XUART2 82
#define TI816XUART3 83
+#define AM33XXUART1 84
#define ZOOM_UART 95 /* Only on zoom2/3 */
/* This is only used by 8250.c for omap1510 */
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-omap/include/plat/uncompress.h
index a067484..bd1e051 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -97,6 +97,10 @@ static inline void flush(void)
_DEBUG_LL_ENTRY(mach, TI816X_UART##p##_BASE, OMAP_PORT_SHIFT, \
TI816XUART##p)
+#define DEBUG_LL_AM33XX(p, mach) \
+ _DEBUG_LL_ENTRY(mach, AM33XX_UART##p##_BASE, OMAP_PORT_SHIFT, \
+ AM33XXUART##p)
+
static inline void __arch_decomp_setup(unsigned long arch_id)
{
int port = 0;
@@ -173,6 +177,8 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
/* TI8168 base boards using UART3 */
DEBUG_LL_TI816X(3, ti8168evm);
+ /* AM33XX base boards using UART1 */
+ DEBUG_LL_AM33XX(1, am335xevm);
} while (0);
}
--
1.7.0.4
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging support
2011-09-20 14:32 ` [PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging support hvaibhav at ti.com
@ 2011-10-06 23:09 ` Tony Lindgren
2011-11-07 15:17 ` Hiremath, Vaibhav
0 siblings, 1 reply; 57+ messages in thread
From: Tony Lindgren @ 2011-10-06 23:09 UTC (permalink / raw)
To: linux-arm-kernel
* hvaibhav at ti.com <hvaibhav@ti.com> [110920 06:59]:
> From: Afzal Mohammed <afzal@ti.com>
>
> Add support for low level debugging on AM335X EVM (AM33XX family).
> Currently only support for UART1 console, which is used on AM335X EVM
> is added.
Let's wait a bit on this one as there are other DEBUG_LL patches
pending from Nico.
Regards,
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging support
2011-10-06 23:09 ` Tony Lindgren
@ 2011-11-07 15:17 ` Hiremath, Vaibhav
2011-11-07 18:16 ` Tony Lindgren
0 siblings, 1 reply; 57+ messages in thread
From: Hiremath, Vaibhav @ 2011-11-07 15:17 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Friday, October 07, 2011 4:39 AM
> To: Hiremath, Vaibhav
> Cc: linux-omap at vger.kernel.org; Hilman, Kevin; paul at pwsan.com; linux-arm-
> kernel at lists.infradead.org; Mohammed, Afzal
> Subject: Re: [PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging
> support
>
> * hvaibhav at ti.com <hvaibhav@ti.com> [110920 06:59]:
> > From: Afzal Mohammed <afzal@ti.com>
> >
> > Add support for low level debugging on AM335X EVM (AM33XX family).
> > Currently only support for UART1 console, which is used on AM335X EVM
> > is added.
>
> Let's wait a bit on this one as there are other DEBUG_LL patches
> pending from Nico.
>
Tony,
Is there any branch or repo against which I can rebase my patches?
Thanks,
Vaibhav
> Regards,
>
> Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging support
2011-11-07 15:17 ` Hiremath, Vaibhav
@ 2011-11-07 18:16 ` Tony Lindgren
0 siblings, 0 replies; 57+ messages in thread
From: Tony Lindgren @ 2011-11-07 18:16 UTC (permalink / raw)
To: linux-arm-kernel
* Hiremath, Vaibhav <hvaibhav@ti.com> [111107 06:42]:
> > -----Original Message-----
> > From: Tony Lindgren [mailto:tony at atomide.com]
> > Sent: Friday, October 07, 2011 4:39 AM
> > To: Hiremath, Vaibhav
> > Cc: linux-omap at vger.kernel.org; Hilman, Kevin; paul at pwsan.com; linux-arm-
> > kernel at lists.infradead.org; Mohammed, Afzal
> > Subject: Re: [PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging
> > support
> >
> > * hvaibhav at ti.com <hvaibhav@ti.com> [110920 06:59]:
> > > From: Afzal Mohammed <afzal@ti.com>
> > >
> > > Add support for low level debugging on AM335X EVM (AM33XX family).
> > > Currently only support for UART1 console, which is used on AM335X EVM
> > > is added.
> >
> > Let's wait a bit on this one as there are other DEBUG_LL patches
> > pending from Nico.
> >
> Tony,
>
> Is there any branch or repo against which I can rebase my patches?
I recommend the current fixes branch.
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 0/3] Introducing TI's New SoC/board AM335XEVM
@ 2011-12-02 6:43 ` hvaibhav at ti.com
2011-12-07 0:24 ` Kevin Hilman
0 siblings, 1 reply; 57+ messages in thread
From: hvaibhav at ti.com @ 2011-12-02 6:43 UTC (permalink / raw)
To: linux-arm-kernel
From: Vaibhav Hiremath <hvaibhav@ti.com>
This patch set adds support for AM335x device having
Cortex-A8 MPU.
Official website - http://www.ti.com/product/am3359
AM335X is treated as another OMAP3 variant, where,
along with existing cpu class OMAP34XX, new cpu class AM33XX is created
and the respective type is AM335X, which is newly added device in
the family.
This means, cpu_is_omap34xx(), cpu_is_am33xx() and
cpu_is_am335x() checks return success for AM335X.
Also, I have validated OMAP3 boot test with this patch-series on
OMAP3EVM.
Changes from V4:
- Patches have been reviewed by Kevin Hilman.
- As per Kevin Hilman's comments updated comment in debug-macro.S,
for AM33XX.
Changes from V3:
- Common platform patch has already been accepted and available
under linux-omap/soc and linux-omap/master branch.
- Clean-up where cpu_is_xxxx instances are being used and patches
has been submitted to the list.
- These patches have been created on top of cleanup patches -
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg58276.html
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg58277.html
- Based on Tony's request, rebased patches against linux-omap/fixes
(+ common platform patch).
Changes from V2(RFC):
- Rebased against Paul's OMAP_CHIP* cleanup patches
git://git.pwsan.com/linux-2.6_omap_chip_remove_cleanup_3.2
Changes from V1(RFC):
- Created separate cpu/SoC class for AM33XX family of devices,
due to all known facts. This is been mentioned in main-chain
https://patchwork.kernel.org/patch/1056312/
- BUG Fix in debug-macro.S, which was leading to build failure.
https://patchwork.kernel.org/patch/1056302/
Afzal Mohammed (3):
arm:omap:am33xx: Update common OMAP machine specific sources
arm:omap:am33xx: Add AM335XEVM machine support
arm:omap:am33xx: Add low level debugging support
arch/arm/mach-omap2/Kconfig | 5 ++++
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/board-am3517evm.c | 21 ++++++++++++++++
arch/arm/mach-omap2/clock3xxx_data.c | 3 ++
arch/arm/mach-omap2/common.c | 21 ++++++++++++++++
arch/arm/mach-omap2/id.c | 6 ++++
arch/arm/mach-omap2/include/mach/debug-macro.S | 17 ++++++++++++-
arch/arm/mach-omap2/io.c | 31 ++++++++++++++++++++++++
arch/arm/mach-omap2/serial.c | 4 +-
arch/arm/mach-omap2/timer.c | 2 +
arch/arm/plat-omap/include/plat/am33xx.h | 25 +++++++++++++++++++
arch/arm/plat-omap/include/plat/common.h | 4 +++
arch/arm/plat-omap/include/plat/hardware.h | 1 +
arch/arm/plat-omap/include/plat/io.h | 20 +++++++++++++++
arch/arm/plat-omap/include/plat/omap34xx.h | 2 +
arch/arm/plat-omap/include/plat/serial.h | 4 +++
arch/arm/plat-omap/include/plat/uncompress.h | 6 ++++
arch/arm/plat-omap/io.c | 5 ++++
18 files changed, 175 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/am33xx.h
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 0/3] Introducing TI's New SoC/board AM335XEVM
2011-12-02 6:43 ` [PATCH-V5 0/3] Introducing TI's New SoC/board AM335XEVM hvaibhav at ti.com
@ 2011-12-07 0:24 ` Kevin Hilman
2011-12-07 21:10 ` Tony Lindgren
0 siblings, 1 reply; 57+ messages in thread
From: Kevin Hilman @ 2011-12-07 0:24 UTC (permalink / raw)
To: linux-arm-kernel
<hvaibhav@ti.com> writes:
> From: Vaibhav Hiremath <hvaibhav@ti.com>
>
> This patch set adds support for AM335x device having
> Cortex-A8 MPU.
>
> Official website - http://www.ti.com/product/am3359
>
> AM335X is treated as another OMAP3 variant, where,
> along with existing cpu class OMAP34XX, new cpu class AM33XX is created
> and the respective type is AM335X, which is newly added device in
> the family.
> This means, cpu_is_omap34xx(), cpu_is_am33xx() and
> cpu_is_am335x() checks return success for AM335X.
>
> Also, I have validated OMAP3 boot test with this patch-series on
> OMAP3EVM.
Tony, this series looks good to me.
I've also tested it on a BeagleBone, so feel free to also add:
Tested-by: Kevin Hilman <khilman@ti.com>
Kevin
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 0/3] Introducing TI's New SoC/board AM335XEVM
2011-12-07 0:24 ` Kevin Hilman
@ 2011-12-07 21:10 ` Tony Lindgren
2011-12-08 13:45 ` Hiremath, Vaibhav
2012-01-18 8:47 ` Hiremath, Vaibhav
0 siblings, 2 replies; 57+ messages in thread
From: Tony Lindgren @ 2011-12-07 21:10 UTC (permalink / raw)
To: linux-arm-kernel
* Kevin Hilman <khilman@ti.com> [111206 15:52]:
> <hvaibhav@ti.com> writes:
>
> > From: Vaibhav Hiremath <hvaibhav@ti.com>
> >
> > This patch set adds support for AM335x device having
> > Cortex-A8 MPU.
> >
> > Official website - http://www.ti.com/product/am3359
> >
> > AM335X is treated as another OMAP3 variant, where,
> > along with existing cpu class OMAP34XX, new cpu class AM33XX is created
> > and the respective type is AM335X, which is newly added device in
> > the family.
> > This means, cpu_is_omap34xx(), cpu_is_am33xx() and
> > cpu_is_am335x() checks return success for AM335X.
> >
> > Also, I have validated OMAP3 boot test with this patch-series on
> > OMAP3EVM.
>
> Tony, this series looks good to me.
>
> I've also tested it on a BeagleBone, so feel free to also add:
>
> Tested-by: Kevin Hilman <khilman@ti.com>
Thanks looks good to me. We still need the machine_id update to
apply patches 2 and 3 in this series, so applying only the first
patch into soc branch for now.
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 0/3] Introducing TI's New SoC/board AM335XEVM
2011-12-07 21:10 ` Tony Lindgren
@ 2011-12-08 13:45 ` Hiremath, Vaibhav
2011-12-08 17:18 ` Tony Lindgren
2012-01-18 8:47 ` Hiremath, Vaibhav
1 sibling, 1 reply; 57+ messages in thread
From: Hiremath, Vaibhav @ 2011-12-08 13:45 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Thursday, December 08, 2011 2:40 AM
> To: Hilman, Kevin
> Cc: Hiremath, Vaibhav; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; paul at pwsan.com
> Subject: Re: [PATCH-V5 0/3] Introducing TI's New SoC/board AM335XEVM
>
> * Kevin Hilman <khilman@ti.com> [111206 15:52]:
> > <hvaibhav@ti.com> writes:
> >
> > > From: Vaibhav Hiremath <hvaibhav@ti.com>
> > >
> > > This patch set adds support for AM335x device having
> > > Cortex-A8 MPU.
> > >
> > > Official website - http://www.ti.com/product/am3359
> > >
> > > AM335X is treated as another OMAP3 variant, where,
> > > along with existing cpu class OMAP34XX, new cpu class AM33XX is
> created
> > > and the respective type is AM335X, which is newly added device in
> > > the family.
> > > This means, cpu_is_omap34xx(), cpu_is_am33xx() and
> > > cpu_is_am335x() checks return success for AM335X.
> > >
> > > Also, I have validated OMAP3 boot test with this patch-series on
> > > OMAP3EVM.
> >
> > Tony, this series looks good to me.
> >
> > I've also tested it on a BeagleBone, so feel free to also add:
> >
> > Tested-by: Kevin Hilman <khilman@ti.com>
>
> Thanks looks good to me. We still need the machine_id update to
> apply patches 2 and 3 in this series, so applying only the first
> patch into soc branch for now.
>
Tony,
Should I ping Russell for this? The machine-id patch is already registered
and present at
http://www.arm.linux.org.uk/developer/machines/download.php
Thanks,
Vaibhav
> Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 0/3] Introducing TI's New SoC/board AM335XEVM
2011-12-08 13:45 ` Hiremath, Vaibhav
@ 2011-12-08 17:18 ` Tony Lindgren
2012-02-01 6:53 ` Hiremath, Vaibhav
0 siblings, 1 reply; 57+ messages in thread
From: Tony Lindgren @ 2011-12-08 17:18 UTC (permalink / raw)
To: linux-arm-kernel
Russell,
* Hiremath, Vaibhav <hvaibhav@ti.com> [111208 05:14]:
> > From: Tony Lindgren [mailto:tony at atomide.com]
> > * Kevin Hilman <khilman@ti.com> [111206 15:52]:
> > >
> > > I've also tested it on a BeagleBone, so feel free to also add:
> > >
> > > Tested-by: Kevin Hilman <khilman@ti.com>
> >
> > Thanks looks good to me. We still need the machine_id update to
> > apply patches 2 and 3 in this series, so applying only the first
> > patch into soc branch for now.
>
> Tony,
>
> Should I ping Russell for this? The machine-id patch is already registered
> and present at
>
> http://www.arm.linux.org.uk/developer/machines/download.php
Care to push the machine_id updates into devel-stable?
Regards,
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 0/3] Introducing TI's New SoC/board AM335XEVM
2011-12-08 17:18 ` Tony Lindgren
@ 2012-02-01 6:53 ` Hiremath, Vaibhav
0 siblings, 0 replies; 57+ messages in thread
From: Hiremath, Vaibhav @ 2012-02-01 6:53 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Dec 08, 2011 at 22:48:54, Tony Lindgren wrote:
> Russell,
>
> * Hiremath, Vaibhav <hvaibhav@ti.com> [111208 05:14]:
> > > From: Tony Lindgren [mailto:tony at atomide.com]
> > > * Kevin Hilman <khilman@ti.com> [111206 15:52]:
> > > >
> > > > I've also tested it on a BeagleBone, so feel free to also add:
> > > >
> > > > Tested-by: Kevin Hilman <khilman@ti.com>
> > >
> > > Thanks looks good to me. We still need the machine_id update to
> > > apply patches 2 and 3 in this series, so applying only the first
> > > patch into soc branch for now.
> >
> > Tony,
> >
> > Should I ping Russell for this? The machine-id patch is already registered
> > and present at
> >
> > http://www.arm.linux.org.uk/developer/machines/download.php
>
> Care to push the machine_id updates into devel-stable?
>
Tony,
Can you merge patches 2 & 3 from this series,
as mach-id for AM335xEVM is already available in Mainline
(linus/master or linux-omap/master)?
Thanks,
Vaibhav
> Regards,
>
> Tony
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 0/3] Introducing TI's New SoC/board AM335XEVM
2011-12-07 21:10 ` Tony Lindgren
2011-12-08 13:45 ` Hiremath, Vaibhav
@ 2012-01-18 8:47 ` Hiremath, Vaibhav
1 sibling, 0 replies; 57+ messages in thread
From: Hiremath, Vaibhav @ 2012-01-18 8:47 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Dec 08, 2011 at 02:40:29, Tony Lindgren wrote:
> * Kevin Hilman <khilman@ti.com> [111206 15:52]:
> > <hvaibhav@ti.com> writes:
> >
> > > From: Vaibhav Hiremath <hvaibhav@ti.com>
> > >
> > > This patch set adds support for AM335x device having
> > > Cortex-A8 MPU.
> > >
> > > Official website - http://www.ti.com/product/am3359
> > >
> > > AM335X is treated as another OMAP3 variant, where,
> > > along with existing cpu class OMAP34XX, new cpu class AM33XX is created
> > > and the respective type is AM335X, which is newly added device in
> > > the family.
> > > This means, cpu_is_omap34xx(), cpu_is_am33xx() and
> > > cpu_is_am335x() checks return success for AM335X.
> > >
> > > Also, I have validated OMAP3 boot test with this patch-series on
> > > OMAP3EVM.
> >
> > Tony, this series looks good to me.
> >
> > I've also tested it on a BeagleBone, so feel free to also add:
> >
> > Tested-by: Kevin Hilman <khilman@ti.com>
>
> Thanks looks good to me. We still need the machine_id update to
> apply patches 2 and 3 in this series, so applying only the first
> patch into soc branch for now.
>
Tony,
Can you also merge this patch, as machine_id for am335x-evm is already
updated in linus/master?
Thanks,
Vaibhav
> Tony
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 1/3] arm:omap:am33xx: Update common OMAP machine specific sources
@ 2011-12-02 6:43 ` hvaibhav at ti.com
2011-12-07 21:09 ` Tony Lindgren
0 siblings, 1 reply; 57+ messages in thread
From: hvaibhav at ti.com @ 2011-12-02 6:43 UTC (permalink / raw)
To: linux-arm-kernel
From: Afzal Mohammed <afzal@ti.com>
This patch updates the common machine specific source files for
support for AM33XX/AM335x with cpu type, macros for identification of
AM33XX/AM335X device.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/clock3xxx_data.c | 3 +++
arch/arm/mach-omap2/common.c | 21 +++++++++++++++++++++
arch/arm/mach-omap2/id.c | 6 ++++++
arch/arm/mach-omap2/io.c | 24 ++++++++++++++++++++++++
arch/arm/mach-omap2/serial.c | 4 ++--
arch/arm/plat-omap/include/plat/am33xx.h | 25 +++++++++++++++++++++++++
arch/arm/plat-omap/include/plat/common.h | 2 ++
arch/arm/plat-omap/include/plat/hardware.h | 1 +
arch/arm/plat-omap/include/plat/io.h | 20 ++++++++++++++++++++
arch/arm/plat-omap/include/plat/omap34xx.h | 2 ++
arch/arm/plat-omap/io.c | 5 +++++
11 files changed, 111 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/am33xx.h
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
index 5d0064a..c1ab6bc 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3517,6 +3517,9 @@ int __init omap3xxx_clk_init(void)
} else if (cpu_is_ti816x()) {
cpu_mask = RATE_IN_TI816X;
cpu_clkflg = CK_TI816X;
+ } else if (cpu_is_am33xx()) {
+ cpu_mask = RATE_IN_AM33XX;
+ cpu_clkflg = CK_AM33XX;
} else if (cpu_is_omap34xx()) {
if (omap_rev() == OMAP3430_REV_ES1_0) {
cpu_mask = RATE_IN_3430ES1;
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 110e5b9..16bac26 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -128,6 +128,27 @@ void __init omap2_set_globals_ti816x(void)
{
__omap2_set_globals(&ti816x_globals);
}
+
+#define AM33XX_TAP_BASE (AM33XX_CTRL_BASE + \
+ TI816X_CONTROL_DEVICE_ID - 0x204)
+
+static struct omap_globals am33xx_globals = {
+ .class = AM335X_CLASS,
+ .tap = AM33XX_L4_WK_IO_ADDRESS(AM33XX_TAP_BASE),
+ .ctrl = AM33XX_L4_WK_IO_ADDRESS(AM33XX_CTRL_BASE),
+ .prm = AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE),
+ .cm = AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE),
+};
+
+void __init omap2_set_globals_am33xx(void)
+{
+ __omap2_set_globals(&am33xx_globals);
+}
+
+void __init am33xx_map_io(void)
+{
+ omapam33xx_map_common_io();
+}
#endif
#if defined(CONFIG_ARCH_OMAP4)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index f1784ee..37fe42f 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -340,6 +340,10 @@ static void __init omap3_check_revision(const char **cpu_rev)
break;
}
break;
+ case 0xb944:
+ omap_revision = AM335X_REV_ES1_0;
+ *cpu_rev = "1.0";
+ break;
default:
/* Unknown default to latest silicon rev as default */
omap_revision = OMAP3630_REV_ES1_2;
@@ -432,6 +436,8 @@ static void __init omap3_cpuinfo(const char *cpu_rev)
cpu_name = (omap3_has_sgx()) ? "AM3517" : "AM3505";
} else if (cpu_is_ti816x()) {
cpu_name = "TI816X";
+ } else if (cpu_is_am335x()) {
+ cpu_name = "AM335X";
} else if (omap3_has_iva() && omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
cpu_name = "OMAP3430/3530";
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index da9bc4a..74e84c6 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -183,7 +183,24 @@ static struct map_desc omapti816x_io_desc[] __initdata = {
.pfn = __phys_to_pfn(L4_34XX_PHYS),
.length = L4_34XX_SIZE,
.type = MT_DEVICE
+ }
+};
+#endif
+
+#ifdef CONFIG_SOC_OMAPAM33XX
+static struct map_desc omapam33xx_io_desc[] __initdata = {
+ {
+ .virtual = L4_34XX_VIRT,
+ .pfn = __phys_to_pfn(L4_34XX_PHYS),
+ .length = L4_34XX_SIZE,
+ .type = MT_DEVICE
},
+ {
+ .virtual = L4_WK_AM33XX_VIRT,
+ .pfn = __phys_to_pfn(L4_WK_AM33XX_PHYS),
+ .length = L4_WK_AM33XX_SIZE,
+ .type = MT_DEVICE
+ }
};
#endif
@@ -270,6 +287,13 @@ void __init omapti816x_map_common_io(void)
}
#endif
+#ifdef CONFIG_SOC_OMAPAM33XX
+void __init omapam33xx_map_common_io(void)
+{
+ iotable_init(omapam33xx_io_desc, ARRAY_SIZE(omapam33xx_io_desc));
+}
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
void __init omap44xx_map_common_io(void)
{
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0dbd5a2..03fc153 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -464,7 +464,7 @@ static void omap_uart_idle_init(struct omap_uart_state *uart)
mod_timer(&uart->timer, jiffies + uart->timeout);
omap_uart_smart_idle_enable(uart, 0);
- if (cpu_is_omap34xx() && !cpu_is_ti816x()) {
+ if (cpu_is_omap34xx() && !(cpu_is_ti816x() || cpu_is_am33xx())) {
u32 mod = (uart->num > 1) ? OMAP3430_PER_MOD : CORE_MOD;
u32 wk_mask = 0;
u32 padconf = 0;
@@ -828,7 +828,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)
}
/* Enable the MDR1 errata for OMAP3 */
- if (cpu_is_omap34xx() && !cpu_is_ti816x())
+ if (cpu_is_omap34xx() && !(cpu_is_ti816x() || cpu_is_am33xx()))
uart->errata |= UART_ERRATA_i202_MDR1_ACCESS;
}
diff --git a/arch/arm/plat-omap/include/plat/am33xx.h b/arch/arm/plat-omap/include/plat/am33xx.h
new file mode 100644
index 0000000..06c19bb
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/am33xx.h
@@ -0,0 +1,25 @@
+/*
+ * This file contains the address info for various AM33XX modules.
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc. - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ASM_ARCH_AM33XX_H
+#define __ASM_ARCH_AM33XX_H
+
+#define L4_SLOW_AM33XX_BASE 0x48000000
+
+#define AM33XX_SCM_BASE 0x44E10000
+#define AM33XX_CTRL_BASE AM33XX_SCM_BASE
+#define AM33XX_PRCM_BASE 0x44E00000
+
+#endif /* __ASM_ARCH_AM33XX_H */
diff --git a/arch/arm/plat-omap/include/plat/common.h b/arch/arm/plat-omap/include/plat/common.h
index 3ff3e36..bb8a6c1 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -82,6 +82,7 @@ void omap2_set_globals_243x(void);
void omap2_set_globals_3xxx(void);
void omap2_set_globals_443x(void);
void omap2_set_globals_ti816x(void);
+void omap2_set_globals_am33xx(void);
/* These get called from omap2_set_globals_xxxx(), do not call these */
void omap2_set_globals_tap(struct omap_globals *);
@@ -92,6 +93,7 @@ void omap2_set_globals_prcm(struct omap_globals *);
void omap242x_map_io(void);
void omap243x_map_io(void);
void omap3_map_io(void);
+void am33xx_map_io(void);
void omap4_map_io(void);
diff --git a/arch/arm/plat-omap/include/plat/hardware.h b/arch/arm/plat-omap/include/plat/hardware.h
index e87efe1..e6521e1 100644
--- a/arch/arm/plat-omap/include/plat/hardware.h
+++ b/arch/arm/plat-omap/include/plat/hardware.h
@@ -287,5 +287,6 @@
#include <plat/omap34xx.h>
#include <plat/omap44xx.h>
#include <plat/ti816x.h>
+#include <plat/am33xx.h>
#endif /* __ASM_ARCH_OMAP_HARDWARE_H */
diff --git a/arch/arm/plat-omap/include/plat/io.h b/arch/arm/plat-omap/include/plat/io.h
index 7f2969e..ffed821 100644
--- a/arch/arm/plat-omap/include/plat/io.h
+++ b/arch/arm/plat-omap/include/plat/io.h
@@ -73,6 +73,9 @@
#define OMAP4_L3_IO_OFFSET 0xb4000000
#define OMAP4_L3_IO_ADDRESS(pa) IOMEM((pa) + OMAP4_L3_IO_OFFSET) /* L3 */
+#define AM33XX_L4_WK_IO_OFFSET 0xb5000000
+#define AM33XX_L4_WK_IO_ADDRESS(pa) IOMEM((pa) + AM33XX_L4_WK_IO_OFFSET)
+
#define OMAP4_L3_PER_IO_OFFSET 0xb1100000
#define OMAP4_L3_PER_IO_ADDRESS(pa) IOMEM((pa) + OMAP4_L3_PER_IO_OFFSET)
@@ -154,6 +157,15 @@
#define L4_34XX_SIZE SZ_4M /* 1MB of 128MB used, want 1MB sect */
/*
+ * ----------------------------------------------------------------------------
+ * AM33XX specific IO mapping
+ * ----------------------------------------------------------------------------
+ */
+#define L4_WK_AM33XX_PHYS L4_WK_AM33XX_BASE
+#define L4_WK_AM33XX_VIRT (L4_WK_AM33XX_PHYS + AM33XX_L4_WK_IO_OFFSET)
+#define L4_WK_AM33XX_SIZE SZ_4M /* 1MB of 128MB used, want 1MB sect */
+
+/*
* Need to look at the Size 4M for L4.
* VPOM3430 was not working for Int controller
*/
@@ -316,6 +328,14 @@ static inline void omapti816x_map_common_io(void)
}
#endif
+#ifdef CONFIG_SOC_OMAPAM33XX
+extern void omapam33xx_map_common_io(void);
+#else
+static inline void omapam33xx_map_common_io(void)
+{
+}
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
extern void omap44xx_map_common_io(void);
#else
diff --git a/arch/arm/plat-omap/include/plat/omap34xx.h b/arch/arm/plat-omap/include/plat/omap34xx.h
index b9e8588..0d818ac 100644
--- a/arch/arm/plat-omap/include/plat/omap34xx.h
+++ b/arch/arm/plat-omap/include/plat/omap34xx.h
@@ -35,6 +35,8 @@
#define L4_EMU_34XX_BASE 0x54000000
#define L3_34XX_BASE 0x68000000
+#define L4_WK_AM33XX_BASE 0x44C00000
+
#define OMAP3430_32KSYNCT_BASE 0x48320000
#define OMAP3430_CM_BASE 0x48004800
#define OMAP3430_PRM_BASE 0x48306800
diff --git a/arch/arm/plat-omap/io.c b/arch/arm/plat-omap/io.c
index 333871f..14c421a 100644
--- a/arch/arm/plat-omap/io.c
+++ b/arch/arm/plat-omap/io.c
@@ -94,6 +94,11 @@ void __iomem *omap_ioremap(unsigned long p, size_t size, unsigned int type)
if (cpu_is_ti816x()) {
if (BETWEEN(p, L4_34XX_PHYS, L4_34XX_SIZE))
return XLATE(p, L4_34XX_PHYS, L4_34XX_VIRT);
+ } else if (cpu_is_am33xx()) {
+ if (BETWEEN(p, L4_34XX_PHYS, L4_34XX_SIZE))
+ return XLATE(p, L4_34XX_PHYS, L4_34XX_VIRT);
+ if (BETWEEN(p, L4_WK_AM33XX_PHYS, L4_WK_AM33XX_SIZE))
+ return XLATE(p, L4_WK_AM33XX_PHYS, L4_WK_AM33XX_VIRT);
} else if (cpu_is_omap34xx()) {
if (BETWEEN(p, L3_34XX_PHYS, L3_34XX_SIZE))
return XLATE(p, L3_34XX_PHYS, L3_34XX_VIRT);
--
1.7.0.4
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH-V5 1/3] arm:omap:am33xx: Update common OMAP machine specific sources
2011-12-02 6:43 ` [PATCH-V5 1/3] arm:omap:am33xx: Update common OMAP machine specific sources hvaibhav at ti.com
@ 2011-12-07 21:09 ` Tony Lindgren
0 siblings, 0 replies; 57+ messages in thread
From: Tony Lindgren @ 2011-12-07 21:09 UTC (permalink / raw)
To: linux-arm-kernel
* hvaibhav at ti.com <hvaibhav@ti.com> [111201 22:08]:
> From: Afzal Mohammed <afzal@ti.com>
>
> This patch updates the common machine specific source files for
> support for AM33XX/AM335x with cpu type, macros for identification of
> AM33XX/AM335X device.
Applying this one updated for the map_io and common.h changes, updated
patch below. The other two will have to wait a little because of the
machine_id dependency.
Regards,
Tony
From: Afzal Mohammed <afzal@ti.com>
Date: Fri, 2 Dec 2011 12:13:22 +0530
Subject: [PATCH] arm:omap:am33xx: Update common OMAP machine specific sources
This patch updates the common machine specific source files for
support for AM33XX/AM335x with cpu type, macros for identification of
AM33XX/AM335X device.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
[tony at atomide.com: updated for map_io and common.h changes]
Signed-off-by: Tony Lindgren <tony@atomide.com>
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
index 5d0064a..c1ab6bc 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3517,6 +3517,9 @@ int __init omap3xxx_clk_init(void)
} else if (cpu_is_ti816x()) {
cpu_mask = RATE_IN_TI816X;
cpu_clkflg = CK_TI816X;
+ } else if (cpu_is_am33xx()) {
+ cpu_mask = RATE_IN_AM33XX;
+ cpu_clkflg = CK_AM33XX;
} else if (cpu_is_omap34xx()) {
if (omap_rev() == OMAP3430_REV_ES1_0) {
cpu_mask = RATE_IN_3430ES1;
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 684b8a7..c900dcb 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -128,6 +128,27 @@ void __init omap2_set_globals_ti816x(void)
{
__omap2_set_globals(&ti816x_globals);
}
+
+#define AM33XX_TAP_BASE (AM33XX_CTRL_BASE + \
+ TI816X_CONTROL_DEVICE_ID - 0x204)
+
+static struct omap_globals am33xx_globals = {
+ .class = AM335X_CLASS,
+ .tap = AM33XX_L4_WK_IO_ADDRESS(AM33XX_TAP_BASE),
+ .ctrl = AM33XX_L4_WK_IO_ADDRESS(AM33XX_CTRL_BASE),
+ .prm = AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE),
+ .cm = AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE),
+};
+
+void __init omap2_set_globals_am33xx(void)
+{
+ __omap2_set_globals(&am33xx_globals);
+}
+
+void __init am33xx_map_io(void)
+{
+ omapam33xx_map_common_io();
+}
#endif
#if defined(CONFIG_ARCH_OMAP4)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 012bac7..9b733e3 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -60,6 +60,14 @@ static inline void omapti816x_map_common_io(void)
}
#endif
+#ifdef CONFIG_SOC_OMAPAM33XX
+extern void omapam33xx_map_common_io(void);
+#else
+static inline void omapam33xx_map_common_io(void)
+{
+}
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
extern void omap44xx_map_common_io(void);
#else
@@ -107,6 +115,7 @@ void omap2_set_globals_243x(void);
void omap2_set_globals_3xxx(void);
void omap2_set_globals_443x(void);
void omap2_set_globals_ti816x(void);
+void omap2_set_globals_am33xx(void);
/* These get called from omap2_set_globals_xxxx(), do not call these */
void omap2_set_globals_tap(struct omap_globals *);
@@ -117,6 +126,7 @@ void omap2_set_globals_prcm(struct omap_globals *);
void omap242x_map_io(void);
void omap243x_map_io(void);
void omap3_map_io(void);
+void am33xx_map_io(void);
void omap4_map_io(void);
/**
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 27ad722..7ab09f7 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -340,6 +340,10 @@ static void __init omap3_check_revision(const char **cpu_rev)
break;
}
break;
+ case 0xb944:
+ omap_revision = AM335X_REV_ES1_0;
+ *cpu_rev = "1.0";
+ break;
default:
/* Unknown default to latest silicon rev as default */
omap_revision = OMAP3630_REV_ES1_2;
@@ -432,6 +436,8 @@ static void __init omap3_cpuinfo(const char *cpu_rev)
cpu_name = (omap3_has_sgx()) ? "AM3517" : "AM3505";
} else if (cpu_is_ti816x()) {
cpu_name = "TI816X";
+ } else if (cpu_is_am335x()) {
+ cpu_name = "AM335X";
} else if (omap3_has_iva() && omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
cpu_name = "OMAP3430/3530";
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3f565dd..088d2ba 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -183,7 +183,24 @@ static struct map_desc omapti816x_io_desc[] __initdata = {
.pfn = __phys_to_pfn(L4_34XX_PHYS),
.length = L4_34XX_SIZE,
.type = MT_DEVICE
+ }
+};
+#endif
+
+#ifdef CONFIG_SOC_OMAPAM33XX
+static struct map_desc omapam33xx_io_desc[] __initdata = {
+ {
+ .virtual = L4_34XX_VIRT,
+ .pfn = __phys_to_pfn(L4_34XX_PHYS),
+ .length = L4_34XX_SIZE,
+ .type = MT_DEVICE
},
+ {
+ .virtual = L4_WK_AM33XX_VIRT,
+ .pfn = __phys_to_pfn(L4_WK_AM33XX_PHYS),
+ .length = L4_WK_AM33XX_SIZE,
+ .type = MT_DEVICE
+ }
};
#endif
@@ -270,6 +287,13 @@ void __init omapti816x_map_common_io(void)
}
#endif
+#ifdef CONFIG_SOC_OMAPAM33XX
+void __init omapam33xx_map_common_io(void)
+{
+ iotable_init(omapam33xx_io_desc, ARRAY_SIZE(omapam33xx_io_desc));
+}
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
void __init omap44xx_map_common_io(void)
{
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 42c3267..9770c76 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -464,7 +464,7 @@ static void omap_uart_idle_init(struct omap_uart_state *uart)
mod_timer(&uart->timer, jiffies + uart->timeout);
omap_uart_smart_idle_enable(uart, 0);
- if (cpu_is_omap34xx() && !cpu_is_ti816x()) {
+ if (cpu_is_omap34xx() && !(cpu_is_ti816x() || cpu_is_am33xx())) {
u32 mod = (uart->num > 1) ? OMAP3430_PER_MOD : CORE_MOD;
u32 wk_mask = 0;
u32 padconf = 0;
@@ -828,7 +828,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)
}
/* Enable the MDR1 errata for OMAP3 */
- if (cpu_is_omap34xx() && !cpu_is_ti816x())
+ if (cpu_is_omap34xx() && !(cpu_is_ti816x() || cpu_is_am33xx()))
uart->errata |= UART_ERRATA_i202_MDR1_ACCESS;
}
diff --git a/arch/arm/plat-omap/include/plat/am33xx.h b/arch/arm/plat-omap/include/plat/am33xx.h
new file mode 100644
index 0000000..06c19bb
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/am33xx.h
@@ -0,0 +1,25 @@
+/*
+ * This file contains the address info for various AM33XX modules.
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc. - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ASM_ARCH_AM33XX_H
+#define __ASM_ARCH_AM33XX_H
+
+#define L4_SLOW_AM33XX_BASE 0x48000000
+
+#define AM33XX_SCM_BASE 0x44E10000
+#define AM33XX_CTRL_BASE AM33XX_SCM_BASE
+#define AM33XX_PRCM_BASE 0x44E00000
+
+#endif /* __ASM_ARCH_AM33XX_H */
diff --git a/arch/arm/plat-omap/include/plat/hardware.h b/arch/arm/plat-omap/include/plat/hardware.h
index e87efe1..e6521e1 100644
--- a/arch/arm/plat-omap/include/plat/hardware.h
+++ b/arch/arm/plat-omap/include/plat/hardware.h
@@ -287,5 +287,6 @@
#include <plat/omap34xx.h>
#include <plat/omap44xx.h>
#include <plat/ti816x.h>
+#include <plat/am33xx.h>
#endif /* __ASM_ARCH_OMAP_HARDWARE_H */
diff --git a/arch/arm/plat-omap/include/plat/io.h b/arch/arm/plat-omap/include/plat/io.h
index 1234944..0696bae 100644
--- a/arch/arm/plat-omap/include/plat/io.h
+++ b/arch/arm/plat-omap/include/plat/io.h
@@ -73,6 +73,9 @@
#define OMAP4_L3_IO_OFFSET 0xb4000000
#define OMAP4_L3_IO_ADDRESS(pa) IOMEM((pa) + OMAP4_L3_IO_OFFSET) /* L3 */
+#define AM33XX_L4_WK_IO_OFFSET 0xb5000000
+#define AM33XX_L4_WK_IO_ADDRESS(pa) IOMEM((pa) + AM33XX_L4_WK_IO_OFFSET)
+
#define OMAP4_L3_PER_IO_OFFSET 0xb1100000
#define OMAP4_L3_PER_IO_ADDRESS(pa) IOMEM((pa) + OMAP4_L3_PER_IO_OFFSET)
@@ -154,6 +157,15 @@
#define L4_34XX_SIZE SZ_4M /* 1MB of 128MB used, want 1MB sect */
/*
+ * ----------------------------------------------------------------------------
+ * AM33XX specific IO mapping
+ * ----------------------------------------------------------------------------
+ */
+#define L4_WK_AM33XX_PHYS L4_WK_AM33XX_BASE
+#define L4_WK_AM33XX_VIRT (L4_WK_AM33XX_PHYS + AM33XX_L4_WK_IO_OFFSET)
+#define L4_WK_AM33XX_SIZE SZ_4M /* 1MB of 128MB used, want 1MB sect */
+
+/*
* Need to look at the Size 4M for L4.
* VPOM3430 was not working for Int controller
*/
diff --git a/arch/arm/plat-omap/include/plat/omap34xx.h b/arch/arm/plat-omap/include/plat/omap34xx.h
index b9e8588..0d818ac 100644
--- a/arch/arm/plat-omap/include/plat/omap34xx.h
+++ b/arch/arm/plat-omap/include/plat/omap34xx.h
@@ -35,6 +35,8 @@
#define L4_EMU_34XX_BASE 0x54000000
#define L3_34XX_BASE 0x68000000
+#define L4_WK_AM33XX_BASE 0x44C00000
+
#define OMAP3430_32KSYNCT_BASE 0x48320000
#define OMAP3430_CM_BASE 0x48004800
#define OMAP3430_PRM_BASE 0x48306800
^ permalink raw reply related [flat|nested] 57+ messages in thread
* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
@ 2011-12-02 6:43 ` hvaibhav at ti.com
2012-05-02 9:23 ` Paul Walmsley
0 siblings, 1 reply; 57+ messages in thread
From: hvaibhav at ti.com @ 2011-12-02 6:43 UTC (permalink / raw)
To: linux-arm-kernel
From: Afzal Mohammed <afzal@ti.com>
This patch adds minimal support for AM335X EVM.
The approach taken here is to add AM335X EVM support
to AM3517EVM, considering the fact that with device tree
developement we will get rid of board-*.c.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/Kconfig | 5 +++++
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/board-am3517evm.c | 21 +++++++++++++++++++++
arch/arm/mach-omap2/io.c | 7 +++++++
arch/arm/mach-omap2/timer.c | 2 ++
arch/arm/plat-omap/include/plat/common.h | 2 ++
6 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 09ea525..c0e4a70 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -326,6 +326,11 @@ config MACH_TI8168EVM
depends on SOC_OMAPTI816X
default y
+config MACH_AM335XEVM
+ bool "AM335X Evaluation Module"
+ depends on SOC_OMAPAM33XX
+ default y
+
config MACH_OMAP_4430SDP
bool "OMAP 4430 SDP board"
default y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index a12a069..89099a3 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -233,6 +233,7 @@ obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o
+obj-$(CONFIG_MACH_AM335XEVM) += board-am3517evm.o
# Platform specific device init code
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index f7df8d3..090457f 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -516,3 +516,24 @@ MACHINE_START(OMAP3517EVM, "OMAP3517/AM3517 EVM")
.init_machine = am3517_evm_init,
.timer = &omap3_timer,
MACHINE_END
+
+static struct omap_board_config_kernel am335x_evm_config[] __initdata = {
+};
+
+static void __init am335x_evm_init(void)
+{
+ omap_serial_init();
+ omap_sdrc_init(NULL, NULL);
+ omap_board_config = am335x_evm_config;
+ omap_board_config_size = ARRAY_SIZE(am335x_evm_config);
+}
+
+MACHINE_START(AM335XEVM, "am335xevm")
+ /* Maintainer: Texas Instruments */
+ .atag_offset = 0x100,
+ .map_io = am33xx_map_io,
+ .init_early = am33xx_init_early,
+ .init_irq = ti816x_init_irq,
+ .timer = &omap3_am33xx_timer,
+ .init_machine = am335x_evm_init,
+MACHINE_END
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 74e84c6..e958c04 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -460,6 +460,13 @@ void __init ti816x_init_early(void)
omap_hwmod_init_postsetup();
omap3xxx_clk_init();
}
+
+void __init am33xx_init_early(void)
+{
+ omap2_set_globals_am33xx();
+ omap_common_init_early();
+ omap3xxx_clk_init();
+}
#endif
#ifdef CONFIG_ARCH_OMAP4
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 037b0d7..7b29197 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -333,6 +333,8 @@ OMAP_SYS_TIMER(3)
OMAP_SYS_TIMER_INIT(3_secure, OMAP3_SECURE_TIMER, OMAP3_CLKEV_SOURCE,
2, OMAP3_MPU_SOURCE)
OMAP_SYS_TIMER(3_secure)
+OMAP_SYS_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, 2, OMAP4_MPU_SOURCE)
+OMAP_SYS_TIMER(3_am33xx)
#endif
#ifdef CONFIG_ARCH_OMAP4
diff --git a/arch/arm/plat-omap/include/plat/common.h b/arch/arm/plat-omap/include/plat/common.h
index bb8a6c1..9d7cc3c 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -39,6 +39,7 @@ extern struct sys_timer omap1_timer;
extern struct sys_timer omap2_timer;
extern struct sys_timer omap3_timer;
extern struct sys_timer omap3_secure_timer;
+extern struct sys_timer omap3_am33xx_timer;
extern struct sys_timer omap4_timer;
extern bool omap_32k_timer_init(void);
extern int __init omap_init_clocksource_32k(void);
@@ -55,6 +56,7 @@ void omap3_init_early(void); /* Do not use this one */
void am35xx_init_early(void);
void ti816x_init_early(void);
void omap4430_init_early(void);
+void am33xx_init_early(void);
extern int omap_dss_reset(struct omap_hwmod *);
--
1.7.0.4
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
2011-12-02 6:43 ` [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support hvaibhav at ti.com
@ 2012-05-02 9:23 ` Paul Walmsley
2012-05-02 9:34 ` Hiremath, Vaibhav
0 siblings, 1 reply; 57+ messages in thread
From: Paul Walmsley @ 2012-05-02 9:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi
On Fri, 2 Dec 2011, hvaibhav at ti.com wrote:
> From: Afzal Mohammed <afzal@ti.com>
>
> This patch adds minimal support for AM335X EVM.
> The approach taken here is to add AM335X EVM support
> to AM3517EVM, considering the fact that with device tree
> developement we will get rid of board-*.c.
>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Reviewed-by: Kevin Hilman <khilman@ti.com>
I realize people may not necessarily like this, but I think that the
AM33xx EVM needs its own board file. This is because it really has
nothing to do with the AM3517EVM. Also, the AM3517EVM depends on
CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on
either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
So the following modification of this patch opts for the former Kconfig
option, CONFIG_ARCH_OMAPAM33XX. It also adds a new, minimal board file
for the AM33xx EVM.
If, on the other hand, people want to use CONFIG_ARCH_OMAP4 instead for
the AM33xx, then we could potentially add the new machine record into
board-omap4panda.c. Although even then, if political considerations were
set aside, the best technical decision would probably be to create a
separate board file, since the boards don't have much in common.
- Paul
From: Afzal Mohammed <afzal@ti.com>
Date: Fri, 2 Dec 2011 12:13:23 +0530
Subject: [PATCH] ARM: OMAP: AM33xx: Add AM335XEVM machine support
This patch adds minimal support for AM335X EVM.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
[paul at pwsan.com: created new board file for AM33xx; moved am33xx_init_early()
outside of CONFIG_ARCH_OMAP3; modified commit message]
---
arch/arm/mach-omap2/Kconfig | 5 ++++
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/board-am335xevm.c | 46 +++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/common.h | 2 ++
arch/arm/mach-omap2/io.c | 8 ++++++
arch/arm/mach-omap2/timer.c | 2 ++
6 files changed, 64 insertions(+)
create mode 100644 arch/arm/mach-omap2/board-am335xevm.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 5ae756a..d5aa936 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -335,6 +335,11 @@ config MACH_TI8148EVM
depends on SOC_OMAPTI81XX
default y
+config MACH_AM335XEVM
+ bool "AM335X Evaluation Module"
+ depends on SOC_OMAPAM33XX
+ default y
+
config MACH_OMAP_4430SDP
bool "OMAP 4430 SDP board"
default y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index c538b3e..d3c33df 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -241,6 +241,7 @@ obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o
obj-$(CONFIG_MACH_TI8148EVM) += board-ti8168evm.o
+obj-$(CONFIG_MACH_AM335XEVM) += board-am335xevm.o
# Platform specific device init code
diff --git a/arch/arm/mach-omap2/board-am335xevm.c b/arch/arm/mach-omap2/board-am335xevm.c
new file mode 100644
index 0000000..324752e
--- /dev/null
+++ b/arch/arm/mach-omap2/board-am335xevm.c
@@ -0,0 +1,46 @@
+/*
+ * board-am335xevm.c - support the TI AM335x EVM board
+ *
+ * Copyright (C) 2011-2012 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+
+#include <mach/hardware.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+
+#include <plat/board.h>
+#include "common.h"
+
+static struct omap_board_config_kernel am335x_evm_config[] __initdata = {
+};
+
+static void __init am335x_evm_init(void)
+{
+ omap_serial_init();
+ omap_sdrc_init(NULL, NULL);
+ omap_board_config = am335x_evm_config;
+ omap_board_config_size = ARRAY_SIZE(am335x_evm_config);
+}
+
+MACHINE_START(AM335XEVM, "am335xevm")
+ /* Maintainer: Texas Instruments */
+ .atag_offset = 0x100,
+ .map_io = am33xx_map_io,
+ .init_early = am33xx_init_early,
+ .init_irq = ti81xx_init_irq,
+ .timer = &omap3_am33xx_timer,
+ .init_machine = am335x_evm_init,
+MACHINE_END
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 57da7f4..dae39a3 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -83,6 +83,7 @@ extern void omap2_init_common_infrastructure(void);
extern struct sys_timer omap2_timer;
extern struct sys_timer omap3_timer;
extern struct sys_timer omap3_secure_timer;
+extern struct sys_timer omap3_am33xx_timer;
extern struct sys_timer omap4_timer;
void omap2420_init_early(void);
@@ -94,6 +95,7 @@ void omap3_init_early(void); /* Do not use this one */
void am35xx_init_early(void);
void ti81xx_init_early(void);
void omap4430_init_early(void);
+void am33xx_init_early(void);
void omap_prcm_restart(char, const char *);
/*
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 065bd76..056db56 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -466,6 +466,14 @@ void __init ti81xx_init_early(void)
omap_hwmod_init_postsetup();
omap3xxx_clk_init();
}
+#endif /* CONFIG_ARCH_OMAP3 */
+
+#ifdef CONFIG_SOC_OMAPAM33XX
+void __init am33xx_init_early(void)
+{
+ omap2_set_globals_am33xx();
+ omap_common_init_early();
+}
#endif
#ifdef CONFIG_ARCH_OMAP4
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index c512bac..b2f747b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -321,6 +321,8 @@ OMAP_SYS_TIMER(3)
OMAP_SYS_TIMER_INIT(3_secure, OMAP3_SECURE_TIMER, OMAP3_CLKEV_SOURCE,
2, OMAP3_MPU_SOURCE)
OMAP_SYS_TIMER(3_secure)
+OMAP_SYS_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, 2, OMAP4_MPU_SOURCE)
+OMAP_SYS_TIMER(3_am33xx)
#endif
#ifdef CONFIG_ARCH_OMAP4
--
1.7.10
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
2012-05-02 9:23 ` Paul Walmsley
@ 2012-05-02 9:34 ` Hiremath, Vaibhav
2012-05-03 15:57 ` Tony Lindgren
0 siblings, 1 reply; 57+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-02 9:34 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> Hi
>
> On Fri, 2 Dec 2011, hvaibhav at ti.com wrote:
>
> > From: Afzal Mohammed <afzal@ti.com>
> >
> > This patch adds minimal support for AM335X EVM.
> > The approach taken here is to add AM335X EVM support
> > to AM3517EVM, considering the fact that with device tree
> > developement we will get rid of board-*.c.
> >
> > Signed-off-by: Afzal Mohammed <afzal@ti.com>
> > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > Reviewed-by: Kevin Hilman <khilman@ti.com>
>
> I realize people may not necessarily like this, but I think that the
> AM33xx EVM needs its own board file. This is because it really has
> nothing to do with the AM3517EVM. Also, the AM3517EVM depends on
> CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on
> either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
>
> So the following modification of this patch opts for the former Kconfig
> option, CONFIG_ARCH_OMAPAM33XX. It also adds a new, minimal board file
> for the AM33xx EVM.
>
> If, on the other hand, people want to use CONFIG_ARCH_OMAP4 instead for
> the AM33xx, then we could potentially add the new machine record into
> board-omap4panda.c. Although even then, if political considerations were
> set aside, the best technical decision would probably be to create a
> separate board file, since the boards don't have much in common.
>
>
Paul,
I completely agree with all of your comments, let Tony comment and conform
on this.
If you go back to history, that was our initial proposal, to create
separate Kconfig option for AM33XX.
Tony,
Can you please comment on this discussion? This is very important, since
lots of patches (accepted or about to accept) are dependent on this. The
early we can conclude on this, early I can rework on the patches and
resubmit them.
Thanks,
Vaibhav
> - Paul
>
> From: Afzal Mohammed <afzal@ti.com>
> Date: Fri, 2 Dec 2011 12:13:23 +0530
> Subject: [PATCH] ARM: OMAP: AM33xx: Add AM335XEVM machine support
>
> This patch adds minimal support for AM335X EVM.
>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Reviewed-by: Kevin Hilman <khilman@ti.com>
> [paul at pwsan.com: created new board file for AM33xx; moved am33xx_init_early()
> outside of CONFIG_ARCH_OMAP3; modified commit message]
> ---
> arch/arm/mach-omap2/Kconfig | 5 ++++
> arch/arm/mach-omap2/Makefile | 1 +
> arch/arm/mach-omap2/board-am335xevm.c | 46 +++++++++++++++++++++++++++++++++
> arch/arm/mach-omap2/common.h | 2 ++
> arch/arm/mach-omap2/io.c | 8 ++++++
> arch/arm/mach-omap2/timer.c | 2 ++
> 6 files changed, 64 insertions(+)
> create mode 100644 arch/arm/mach-omap2/board-am335xevm.c
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 5ae756a..d5aa936 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -335,6 +335,11 @@ config MACH_TI8148EVM
> depends on SOC_OMAPTI81XX
> default y
>
> +config MACH_AM335XEVM
> + bool "AM335X Evaluation Module"
> + depends on SOC_OMAPAM33XX
> + default y
> +
> config MACH_OMAP_4430SDP
> bool "OMAP 4430 SDP board"
> default y
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index c538b3e..d3c33df 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -241,6 +241,7 @@ obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
> obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
> obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o
> obj-$(CONFIG_MACH_TI8148EVM) += board-ti8168evm.o
> +obj-$(CONFIG_MACH_AM335XEVM) += board-am335xevm.o
>
> # Platform specific device init code
>
> diff --git a/arch/arm/mach-omap2/board-am335xevm.c b/arch/arm/mach-omap2/board-am335xevm.c
> new file mode 100644
> index 0000000..324752e
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-am335xevm.c
> @@ -0,0 +1,46 @@
> +/*
> + * board-am335xevm.c - support the TI AM335x EVM board
> + *
> + * Copyright (C) 2011-2012 Texas Instruments, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +
> +#include <mach/hardware.h>
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +#include <asm/mach/map.h>
> +
> +#include <plat/board.h>
> +#include "common.h"
> +
> +static struct omap_board_config_kernel am335x_evm_config[] __initdata = {
> +};
> +
> +static void __init am335x_evm_init(void)
> +{
> + omap_serial_init();
> + omap_sdrc_init(NULL, NULL);
> + omap_board_config = am335x_evm_config;
> + omap_board_config_size = ARRAY_SIZE(am335x_evm_config);
> +}
> +
> +MACHINE_START(AM335XEVM, "am335xevm")
> + /* Maintainer: Texas Instruments */
> + .atag_offset = 0x100,
> + .map_io = am33xx_map_io,
> + .init_early = am33xx_init_early,
> + .init_irq = ti81xx_init_irq,
> + .timer = &omap3_am33xx_timer,
> + .init_machine = am335x_evm_init,
> +MACHINE_END
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 57da7f4..dae39a3 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -83,6 +83,7 @@ extern void omap2_init_common_infrastructure(void);
> extern struct sys_timer omap2_timer;
> extern struct sys_timer omap3_timer;
> extern struct sys_timer omap3_secure_timer;
> +extern struct sys_timer omap3_am33xx_timer;
> extern struct sys_timer omap4_timer;
>
> void omap2420_init_early(void);
> @@ -94,6 +95,7 @@ void omap3_init_early(void); /* Do not use this one */
> void am35xx_init_early(void);
> void ti81xx_init_early(void);
> void omap4430_init_early(void);
> +void am33xx_init_early(void);
> void omap_prcm_restart(char, const char *);
>
> /*
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index 065bd76..056db56 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -466,6 +466,14 @@ void __init ti81xx_init_early(void)
> omap_hwmod_init_postsetup();
> omap3xxx_clk_init();
> }
> +#endif /* CONFIG_ARCH_OMAP3 */
> +
> +#ifdef CONFIG_SOC_OMAPAM33XX
> +void __init am33xx_init_early(void)
> +{
> + omap2_set_globals_am33xx();
> + omap_common_init_early();
> +}
> #endif
>
> #ifdef CONFIG_ARCH_OMAP4
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index c512bac..b2f747b 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -321,6 +321,8 @@ OMAP_SYS_TIMER(3)
> OMAP_SYS_TIMER_INIT(3_secure, OMAP3_SECURE_TIMER, OMAP3_CLKEV_SOURCE,
> 2, OMAP3_MPU_SOURCE)
> OMAP_SYS_TIMER(3_secure)
> +OMAP_SYS_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, 2, OMAP4_MPU_SOURCE)
> +OMAP_SYS_TIMER(3_am33xx)
> #endif
>
> #ifdef CONFIG_ARCH_OMAP4
> --
> 1.7.10
>
>
^ permalink raw reply [flat|nested] 57+ messages in thread* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
2012-05-02 9:34 ` Hiremath, Vaibhav
@ 2012-05-03 15:57 ` Tony Lindgren
2012-05-03 16:41 ` Hiremath, Vaibhav
2012-05-04 6:28 ` Hiremath, Vaibhav
0 siblings, 2 replies; 57+ messages in thread
From: Tony Lindgren @ 2012-05-03 15:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
* Hiremath, Vaibhav <hvaibhav@ti.com> [120502 02:37]:
> On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> > Hi
> >
> > On Fri, 2 Dec 2011, hvaibhav at ti.com wrote:
> >
> > > From: Afzal Mohammed <afzal@ti.com>
> > >
> > > This patch adds minimal support for AM335X EVM.
> > > The approach taken here is to add AM335X EVM support
> > > to AM3517EVM, considering the fact that with device tree
> > > developement we will get rid of board-*.c.
> > >
> > > Signed-off-by: Afzal Mohammed <afzal@ti.com>
> > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > > Reviewed-by: Kevin Hilman <khilman@ti.com>
> >
> > I realize people may not necessarily like this, but I think that the
> > AM33xx EVM needs its own board file. This is because it really has
> > nothing to do with the AM3517EVM. Also, the AM3517EVM depends on
> > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on
> > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
except core with omap3. And the SOC is independent of the core selected,
there is no dependency between SoC and the core.
Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
compile with different flags either.
> > So the following modification of this patch opts for the former Kconfig
> > option, CONFIG_ARCH_OMAPAM33XX. It also adds a new, minimal board file
> > for the AM33xx EVM.
Sorry, no more new board files. Please make it device tree only then.
> > If, on the other hand, people want to use CONFIG_ARCH_OMAP4 instead for
> > the AM33xx, then we could potentially add the new machine record into
> > board-omap4panda.c. Although even then, if political considerations were
> > set aside, the best technical decision would probably be to create a
> > separate board file, since the boards don't have much in common.
> >
> >
> Paul,
> I completely agree with all of your comments, let Tony comment and conform
> on this.
> If you go back to history, that was our initial proposal, to create
> separate Kconfig option for AM33XX.
>
> Tony,
>
> Can you please comment on this discussion? This is very important, since
> lots of patches (accepted or about to accept) are dependent on this. The
> early we can conclude on this, early I can rework on the patches and
> resubmit them.
Yes, please do. Also note that if this means sprinkling tons of cpu_is_omapxxx
all over the code, we need to find a cleaner solution.
Regards,
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
2012-05-03 15:57 ` Tony Lindgren
@ 2012-05-03 16:41 ` Hiremath, Vaibhav
2012-05-03 19:37 ` Tony Lindgren
2012-05-03 21:17 ` Kevin Hilman
2012-05-04 6:28 ` Hiremath, Vaibhav
1 sibling, 2 replies; 57+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-03 16:41 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
> Hi,
>
> * Hiremath, Vaibhav <hvaibhav@ti.com> [120502 02:37]:
> > On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> > > Hi
> > >
> > > On Fri, 2 Dec 2011, hvaibhav at ti.com wrote:
> > >
> > > > From: Afzal Mohammed <afzal@ti.com>
> > > >
> > > > This patch adds minimal support for AM335X EVM.
> > > > The approach taken here is to add AM335X EVM support
> > > > to AM3517EVM, considering the fact that with device tree
> > > > developement we will get rid of board-*.c.
> > > >
> > > > Signed-off-by: Afzal Mohammed <afzal@ti.com>
> > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > > > Reviewed-by: Kevin Hilman <khilman@ti.com>
> > >
> > > I realize people may not necessarily like this, but I think that the
> > > AM33xx EVM needs its own board file. This is because it really has
> > > nothing to do with the AM3517EVM. Also, the AM3517EVM depends on
> > > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on
> > > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
>
> I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
> except core with omap3. And the SOC is independent of the core selected,
> there is no dependency between SoC and the core.
>
> Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
> CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
> compile with different flags either.
>
What about cpu_is_omap34xx() true for am33xx? Should we follow it?
Thanks,
Vaibhav
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
2012-05-03 16:41 ` Hiremath, Vaibhav
@ 2012-05-03 19:37 ` Tony Lindgren
2012-05-04 6:14 ` Hiremath, Vaibhav
2012-05-03 21:17 ` Kevin Hilman
1 sibling, 1 reply; 57+ messages in thread
From: Tony Lindgren @ 2012-05-03 19:37 UTC (permalink / raw)
To: linux-arm-kernel
* Hiremath, Vaibhav <hvaibhav@ti.com> [120503 09:45]:
>
> What about cpu_is_omap34xx() true for am33xx? Should we follow it?
Well are there components that could be used as is with that?
If not, then it probably does not make sense.
BTW, you should post your patches on top of the clean-up patches
Santosh posted as that already leaves out some cpu_is_omapxxxx
checks. That's the "ARM: OMAP2+: Misc cleanup" thread.
Regards,
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
2012-05-03 19:37 ` Tony Lindgren
@ 2012-05-04 6:14 ` Hiremath, Vaibhav
0 siblings, 0 replies; 57+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-04 6:14 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 04, 2012 at 01:07:32, Tony Lindgren wrote:
> * Hiremath, Vaibhav <hvaibhav@ti.com> [120503 09:45]:
> >
> > What about cpu_is_omap34xx() true for am33xx? Should we follow it?
>
> Well are there components that could be used as is with that?
> If not, then it probably does not make sense.
>
I am also in favor of not following cpu_is_omap34xx() for am33xx, but what about ARCH_OMAP?
I don't see that you are in agreement in creating ARCH_OMAPAM33XX.
Does it make sense to say that, for am33xx, cpu_is_omap34xx() is false, but still it is under ARCH_OMAP3?
> BTW, you should post your patches on top of the clean-up patches
> Santosh posted as that already leaves out some cpu_is_omapxxxx
> checks. That's the "ARM: OMAP2+: Misc cleanup" thread.
>
Ok. I will do that.
Thanks,
Vaibhav
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
2012-05-03 16:41 ` Hiremath, Vaibhav
2012-05-03 19:37 ` Tony Lindgren
@ 2012-05-03 21:17 ` Kevin Hilman
2012-05-04 6:00 ` Hiremath, Vaibhav
1 sibling, 1 reply; 57+ messages in thread
From: Kevin Hilman @ 2012-05-03 21:17 UTC (permalink / raw)
To: linux-arm-kernel
"Hiremath, Vaibhav" <hvaibhav@ti.com> writes:
> On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
>> Hi,
>>
>> * Hiremath, Vaibhav <hvaibhav@ti.com> [120502 02:37]:
>> > On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
>> > > Hi
>> > >
>> > > On Fri, 2 Dec 2011, hvaibhav at ti.com wrote:
>> > >
>> > > > From: Afzal Mohammed <afzal@ti.com>
>> > > >
>> > > > This patch adds minimal support for AM335X EVM.
>> > > > The approach taken here is to add AM335X EVM support
>> > > > to AM3517EVM, considering the fact that with device tree
>> > > > developement we will get rid of board-*.c.
>> > > >
>> > > > Signed-off-by: Afzal Mohammed <afzal@ti.com>
>> > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
>> > > > Reviewed-by: Kevin Hilman <khilman@ti.com>
>> > >
>> > > I realize people may not necessarily like this, but I think that the
>> > > AM33xx EVM needs its own board file. This is because it really has
>> > > nothing to do with the AM3517EVM. Also, the AM3517EVM depends on
>> > > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on
>> > > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
>>
>> I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
>> except core with omap3. And the SOC is independent of the core selected,
>> there is no dependency between SoC and the core.
>>
>> Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
>> CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
>> compile with different flags either.
>>
>
> What about cpu_is_omap34xx() true for am33xx? Should we follow it?
Please, no.
I've already demonstrated that that is not necessary and only leads to
confusion and maintenance headaches.
Kevin
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
2012-05-03 21:17 ` Kevin Hilman
@ 2012-05-04 6:00 ` Hiremath, Vaibhav
2012-05-04 20:05 ` Tony Lindgren
0 siblings, 1 reply; 57+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-04 6:00 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 04, 2012 at 02:47:34, Hilman, Kevin wrote:
> "Hiremath, Vaibhav" <hvaibhav@ti.com> writes:
>
> > On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
> >> Hi,
> >>
> >> * Hiremath, Vaibhav <hvaibhav@ti.com> [120502 02:37]:
> >> > On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> >> > > Hi
> >> > >
> >> > > On Fri, 2 Dec 2011, hvaibhav at ti.com wrote:
> >> > >
> >> > > > From: Afzal Mohammed <afzal@ti.com>
> >> > > >
> >> > > > This patch adds minimal support for AM335X EVM.
> >> > > > The approach taken here is to add AM335X EVM support
> >> > > > to AM3517EVM, considering the fact that with device tree
> >> > > > developement we will get rid of board-*.c.
> >> > > >
> >> > > > Signed-off-by: Afzal Mohammed <afzal@ti.com>
> >> > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> >> > > > Reviewed-by: Kevin Hilman <khilman@ti.com>
> >> > >
> >> > > I realize people may not necessarily like this, but I think that the
> >> > > AM33xx EVM needs its own board file. This is because it really has
> >> > > nothing to do with the AM3517EVM. Also, the AM3517EVM depends on
> >> > > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on
> >> > > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
> >>
> >> I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
> >> except core with omap3. And the SOC is independent of the core selected,
> >> there is no dependency between SoC and the core.
> >>
> >> Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
> >> CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
> >> compile with different flags either.
> >>
> >
> > What about cpu_is_omap34xx() true for am33xx? Should we follow it?
>
> Please, no.
>
> I've already demonstrated that that is not necessary and only leads to
> confusion and maintenance headaches.
>
That's what I was expecting...
Probably last question where I have confusion,
Tony, seems to be against adding new ARCH_OMAPAM33XX, but which _ARCH_ we need to follow for AM33XX?
I have to choose between ARCH_OMAP3 or ARCH_OMAP4 and what should I choose
here?
Does it make sense to follow ARCH_OMAPx but not follow cpu_is_omapxxx()?
OR
Should we create ARCH_AMXXXX, assuming that all AM devices have similar
memory map layout, interrupt mapping, etc...
OR
Should I just add SOC_OMAPAM33XX, wherever required?
Also, there are lot of thing wrapped under ARCH_OMAP3 || ARCH_OMAP4 option, which is required for AM33XX, how should we handle this?
For example,
"arch/arm/plat-omap/include/plat/clock.h"
struct dpll_data {
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
<dpll related variables>
#endif
};
"arch/arm/mach-omap2/clock.c"
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
const struct clkops clkops_omap3_noncore_dpll_ops = {
};
const struct clkops clkops_omap3_core_dpll_ops = {
}
^ permalink raw reply [flat|nested] 57+ messages in thread* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
2012-05-04 6:00 ` Hiremath, Vaibhav
@ 2012-05-04 20:05 ` Tony Lindgren
2012-05-07 14:38 ` Hiremath, Vaibhav
0 siblings, 1 reply; 57+ messages in thread
From: Tony Lindgren @ 2012-05-04 20:05 UTC (permalink / raw)
To: linux-arm-kernel
* Hiremath, Vaibhav <hvaibhav@ti.com> [120503 23:04]:
>
> Tony, seems to be against adding new ARCH_OMAPAM33XX, but which _ARCH_ we need to follow for AM33XX?
> I have to choose between ARCH_OMAP3 or ARCH_OMAP4 and what should I choose
> here?
I think you're getting confused now :) I'm against ARCH_XXX but I'm OK with
adding SOC_XXX.
We should only need ARCH_OMAP2PLUS + SOC_XXX, there should not be any need
to add new ARCH_XXX under mach-omap2. Whatever we have left for ARCH_OMAP
in mach-omap2 will be eventually converted to SOC_OMAP.
> Does it make sense to follow ARCH_OMAPx but not follow cpu_is_omapxxx()?
> OR
No
> Should we create ARCH_AMXXXX, assuming that all AM devices have similar
No
> memory map layout, interrupt mapping, etc...
> OR
> Should I just add SOC_OMAPAM33XX, wherever required?
Yes, but how about just use SOC_AM33XX?
> Also, there are lot of thing wrapped under ARCH_OMAP3 || ARCH_OMAP4 option, which is required for AM33XX, how should we handle this?
>
> For example,
>
> "arch/arm/plat-omap/include/plat/clock.h"
> struct dpll_data {
> #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
> <dpll related variables>
> #endif
> };
>
> "arch/arm/mach-omap2/clock.c"
>
> #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
>
> const struct clkops clkops_omap3_noncore_dpll_ops = {
> };
> const struct clkops clkops_omap3_core_dpll_ops = {
> }
I suggest doing some clean-up patches before adding SOC_AM33XX where
you just convert those to be
#if defined(CONFIG_ARCH_OMAP2PLUS) && !defined(CONFIG_ARCH_OMAP2)
or something similar depending if they already are inside mach-omap2
directory. This will make them future proof for adding new SoCs
without having to patch all over the place.
Regards,
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
2012-05-04 20:05 ` Tony Lindgren
@ 2012-05-07 14:38 ` Hiremath, Vaibhav
2012-05-07 17:32 ` Tony Lindgren
0 siblings, 1 reply; 57+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-07 14:38 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, May 05, 2012 at 01:35:47, Tony Lindgren wrote:
> * Hiremath, Vaibhav <hvaibhav@ti.com> [120503 23:04]:
> >
> > Tony, seems to be against adding new ARCH_OMAPAM33XX, but which _ARCH_ we need to follow for AM33XX?
> > I have to choose between ARCH_OMAP3 or ARCH_OMAP4 and what should I choose
> > here?
>
> I think you're getting confused now :) I'm against ARCH_XXX but I'm OK with
> adding SOC_XXX.
>
> We should only need ARCH_OMAP2PLUS + SOC_XXX, there should not be any need
> to add new ARCH_XXX under mach-omap2. Whatever we have left for ARCH_OMAP
> in mach-omap2 will be eventually converted to SOC_OMAP.
>
> > Does it make sense to follow ARCH_OMAPx but not follow cpu_is_omapxxx()?
> > OR
>
> No
>
> > Should we create ARCH_AMXXXX, assuming that all AM devices have similar
>
> No
>
> > memory map layout, interrupt mapping, etc...
> > OR
> > Should I just add SOC_OMAPAM33XX, wherever required?
>
> Yes, but how about just use SOC_AM33XX?
>
I will submit patches shortly (in the last cleanup now), where for am33xx
- cpu_is_omap34xx() will be false.
- Only cpu_is_am33xx() will be true here.
- Neither be under ARCH_OMAP3 nor ARCH_OMAP4, instead will be an
independent device under SOC_OMAPAM33XX.
This brings-in, some cleanup in existing code, which I will also submit
shortly.
> > Also, there are lot of thing wrapped under ARCH_OMAP3 || ARCH_OMAP4 option, which is required for AM33XX, how should we handle this?
> >
> > For example,
> >
> > "arch/arm/plat-omap/include/plat/clock.h"
> > struct dpll_data {
> > #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
> > <dpll related variables>
> > #endif
> > };
> >
> > "arch/arm/mach-omap2/clock.c"
> >
> > #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
> >
> > const struct clkops clkops_omap3_noncore_dpll_ops = {
> > };
> > const struct clkops clkops_omap3_core_dpll_ops = {
> > }
>
> I suggest doing some clean-up patches before adding SOC_AM33XX where
> you just convert those to be
>
> #if defined(CONFIG_ARCH_OMAP2PLUS) && !defined(CONFIG_ARCH_OMAP2)
>
> or something similar depending if they already are inside mach-omap2
> directory. This will make them future proof for adding new SoCs
> without having to patch all over the place.
>
Tony,
Cool, I also thought exactly same solution on this, but next thought came to
my mind was, it won't scale up, since we still have dependency on ARCH_OMAP2
option. However, it will be a good temporary solution for our problem, lets
review them first (I will submit shortly).
Thanks,
Vaibhav
^ permalink raw reply [flat|nested] 57+ messages in thread* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
2012-05-07 14:38 ` Hiremath, Vaibhav
@ 2012-05-07 17:32 ` Tony Lindgren
2012-05-07 18:55 ` Hiremath, Vaibhav
0 siblings, 1 reply; 57+ messages in thread
From: Tony Lindgren @ 2012-05-07 17:32 UTC (permalink / raw)
To: linux-arm-kernel
* Hiremath, Vaibhav <hvaibhav@ti.com> [120507 07:41]:
> On Sat, May 05, 2012 at 01:35:47, Tony Lindgren wrote:
> >
> > I suggest doing some clean-up patches before adding SOC_AM33XX where
> > you just convert those to be
> >
> > #if defined(CONFIG_ARCH_OMAP2PLUS) && !defined(CONFIG_ARCH_OMAP2)
> >
> > or something similar depending if they already are inside mach-omap2
> > directory. This will make them future proof for adding new SoCs
> > without having to patch all over the place.
BTW, just noticied that the above won't work the right way in the
multi-omap case when all of them are compiled in..
> Cool, I also thought exactly same solution on this, but next thought came to
> my mind was, it won't scale up, since we still have dependency on ARCH_OMAP2
> option. However, it will be a good temporary solution for our problem, lets
> review them first (I will submit shortly).
..so probably the best way to deal with that is with the additional
CONFIG_SOC_OMAP3PLUS and CONFIG_SOC_OMAP4PLUS options that I posted
at:
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg67938.html
Can you please take a look and see how that works for am33xx?
Regards,
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
2012-05-07 17:32 ` Tony Lindgren
@ 2012-05-07 18:55 ` Hiremath, Vaibhav
2012-05-08 19:06 ` Tony Lindgren
0 siblings, 1 reply; 57+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-07 18:55 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, May 07, 2012 at 23:02:29, Tony Lindgren wrote:
> * Hiremath, Vaibhav <hvaibhav@ti.com> [120507 07:41]:
> > On Sat, May 05, 2012 at 01:35:47, Tony Lindgren wrote:
> > >
> > > I suggest doing some clean-up patches before adding SOC_AM33XX where
> > > you just convert those to be
> > >
> > > #if defined(CONFIG_ARCH_OMAP2PLUS) && !defined(CONFIG_ARCH_OMAP2)
> > >
> > > or something similar depending if they already are inside mach-omap2
> > > directory. This will make them future proof for adding new SoCs
> > > without having to patch all over the place.
>
> BTW, just noticied that the above won't work the right way in the
> multi-omap case when all of them are compiled in..
>
> > Cool, I also thought exactly same solution on this, but next thought came to
> > my mind was, it won't scale up, since we still have dependency on ARCH_OMAP2
> > option. However, it will be a good temporary solution for our problem, lets
> > review them first (I will submit shortly).
>
> ..so probably the best way to deal with that is with the additional
> CONFIG_SOC_OMAP3PLUS and CONFIG_SOC_OMAP4PLUS options that I posted
> at:
>
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg67938.html
>
> Can you please take a look and see how that works for am33xx?
>
I still don't understand, how this will help am33xx, and for that matter any
new future devices based on cortex-a8 or a9 core, but not omap exactly
families?
As I said earlier, am33xx doesn't fall under either omap3 or omap4; we have
again same question in front of us, which to follow, either omap3 or omap4??
What is the thought process of creating these config options? Isn't it same
as just replacing ARCH_OMAP3/4 with SOC_OMAP3PLUS and SOC_OMAP4PLUS? What is
the criteria for the device to get into this umbrella?
Thanks,
Vaibhav
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
2012-05-07 18:55 ` Hiremath, Vaibhav
@ 2012-05-08 19:06 ` Tony Lindgren
2012-05-08 19:57 ` Hiremath, Vaibhav
0 siblings, 1 reply; 57+ messages in thread
From: Tony Lindgren @ 2012-05-08 19:06 UTC (permalink / raw)
To: linux-arm-kernel
* Hiremath, Vaibhav <hvaibhav@ti.com> [120507 11:59]:
> On Mon, May 07, 2012 at 23:02:29, Tony Lindgren wrote:
> > * Hiremath, Vaibhav <hvaibhav@ti.com> [120507 07:41]:
> > > On Sat, May 05, 2012 at 01:35:47, Tony Lindgren wrote:
> > > >
> > > > I suggest doing some clean-up patches before adding SOC_AM33XX where
> > > > you just convert those to be
> > > >
> > > > #if defined(CONFIG_ARCH_OMAP2PLUS) && !defined(CONFIG_ARCH_OMAP2)
> > > >
> > > > or something similar depending if they already are inside mach-omap2
> > > > directory. This will make them future proof for adding new SoCs
> > > > without having to patch all over the place.
> >
> > BTW, just noticied that the above won't work the right way in the
> > multi-omap case when all of them are compiled in..
> >
> > > Cool, I also thought exactly same solution on this, but next thought came to
> > > my mind was, it won't scale up, since we still have dependency on ARCH_OMAP2
> > > option. However, it will be a good temporary solution for our problem, lets
> > > review them first (I will submit shortly).
> >
> > ..so probably the best way to deal with that is with the additional
> > CONFIG_SOC_OMAP3PLUS and CONFIG_SOC_OMAP4PLUS options that I posted
> > at:
> >
> > http://www.mail-archive.com/linux-omap at vger.kernel.org/msg67938.html
> >
> > Can you please take a look and see how that works for am33xx?
> >
>
> I still don't understand, how this will help am33xx, and for that matter any
> new future devices based on cortex-a8 or a9 core, but not omap exactly
> families?
> As I said earlier, am33xx doesn't fall under either omap3 or omap4; we have
> again same question in front of us, which to follow, either omap3 or omap4??
>
> What is the thought process of creating these config options? Isn't it same
> as just replacing ARCH_OMAP3/4 with SOC_OMAP3PLUS and SOC_OMAP4PLUS? What is
> the criteria for the device to get into this umbrella?
Just to recap: As we've discussed elsewhere, these new options need to be finer
grained SOC_HAS_OMAPXYZ_ABC type options like you've already posted.
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
2012-05-08 19:06 ` Tony Lindgren
@ 2012-05-08 19:57 ` Hiremath, Vaibhav
0 siblings, 0 replies; 57+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-08 19:57 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, May 09, 2012 at 00:36:51, Tony Lindgren wrote:
> * Hiremath, Vaibhav <hvaibhav@ti.com> [120507 11:59]:
> > On Mon, May 07, 2012 at 23:02:29, Tony Lindgren wrote:
> > > * Hiremath, Vaibhav <hvaibhav@ti.com> [120507 07:41]:
> > > > On Sat, May 05, 2012 at 01:35:47, Tony Lindgren wrote:
> > > > >
> > > > > I suggest doing some clean-up patches before adding SOC_AM33XX where
> > > > > you just convert those to be
> > > > >
> > > > > #if defined(CONFIG_ARCH_OMAP2PLUS) && !defined(CONFIG_ARCH_OMAP2)
> > > > >
> > > > > or something similar depending if they already are inside mach-omap2
> > > > > directory. This will make them future proof for adding new SoCs
> > > > > without having to patch all over the place.
> > >
> > > BTW, just noticied that the above won't work the right way in the
> > > multi-omap case when all of them are compiled in..
> > >
> > > > Cool, I also thought exactly same solution on this, but next thought came to
> > > > my mind was, it won't scale up, since we still have dependency on ARCH_OMAP2
> > > > option. However, it will be a good temporary solution for our problem, lets
> > > > review them first (I will submit shortly).
> > >
> > > ..so probably the best way to deal with that is with the additional
> > > CONFIG_SOC_OMAP3PLUS and CONFIG_SOC_OMAP4PLUS options that I posted
> > > at:
> > >
> > > http://www.mail-archive.com/linux-omap at vger.kernel.org/msg67938.html
> > >
> > > Can you please take a look and see how that works for am33xx?
> > >
> >
> > I still don't understand, how this will help am33xx, and for that matter any
> > new future devices based on cortex-a8 or a9 core, but not omap exactly
> > families?
> > As I said earlier, am33xx doesn't fall under either omap3 or omap4; we have
> > again same question in front of us, which to follow, either omap3 or omap4??
> >
> > What is the thought process of creating these config options? Isn't it same
> > as just replacing ARCH_OMAP3/4 with SOC_OMAP3PLUS and SOC_OMAP4PLUS? What is
> > the criteria for the device to get into this umbrella?
>
> Just to recap: As we've discussed elsewhere, these new options need to be finer
> grained SOC_HAS_OMAPXYZ_ABC type options like you've already posted.
>
Absolutely... I will be submitting machine and low-level early printk patch
Based on this only.
Thanks,
Vaibhav
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
2012-05-03 15:57 ` Tony Lindgren
2012-05-03 16:41 ` Hiremath, Vaibhav
@ 2012-05-04 6:28 ` Hiremath, Vaibhav
2012-05-04 20:00 ` Tony Lindgren
1 sibling, 1 reply; 57+ messages in thread
From: Hiremath, Vaibhav @ 2012-05-04 6:28 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
> Hi,
>
> * Hiremath, Vaibhav <hvaibhav@ti.com> [120502 02:37]:
> > On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> > > Hi
> > >
> > > On Fri, 2 Dec 2011, hvaibhav at ti.com wrote:
> > >
> > > > From: Afzal Mohammed <afzal@ti.com>
> > > >
> > > > This patch adds minimal support for AM335X EVM.
> > > > The approach taken here is to add AM335X EVM support
> > > > to AM3517EVM, considering the fact that with device tree
> > > > developement we will get rid of board-*.c.
> > > >
> > > > Signed-off-by: Afzal Mohammed <afzal@ti.com>
> > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > > > Reviewed-by: Kevin Hilman <khilman@ti.com>
> > >
> > > I realize people may not necessarily like this, but I think that the
> > > AM33xx EVM needs its own board file. This is because it really has
> > > nothing to do with the AM3517EVM. Also, the AM3517EVM depends on
> > > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on
> > > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
>
> I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
> except core with omap3. And the SOC is independent of the core selected,
> there is no dependency between SoC and the core.
>
> Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
> CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
> compile with different flags either.
>
But still we do have ARCH_OMAP2, ARCH_OMAP3 and ARCH_OMAP4? And that's where,
we have issues for adding new devices like AM33xx and TI81xx.
Thanks,
Vaibhav
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support
2012-05-04 6:28 ` Hiremath, Vaibhav
@ 2012-05-04 20:00 ` Tony Lindgren
0 siblings, 0 replies; 57+ messages in thread
From: Tony Lindgren @ 2012-05-04 20:00 UTC (permalink / raw)
To: linux-arm-kernel
* Hiremath, Vaibhav <hvaibhav@ti.com> [120503 23:31]:
> On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
> > Hi,
> >
> > * Hiremath, Vaibhav <hvaibhav@ti.com> [120502 02:37]:
> > > On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> > > > Hi
> > > >
> > > > On Fri, 2 Dec 2011, hvaibhav at ti.com wrote:
> > > >
> > > > > From: Afzal Mohammed <afzal@ti.com>
> > > > >
> > > > > This patch adds minimal support for AM335X EVM.
> > > > > The approach taken here is to add AM335X EVM support
> > > > > to AM3517EVM, considering the fact that with device tree
> > > > > developement we will get rid of board-*.c.
> > > > >
> > > > > Signed-off-by: Afzal Mohammed <afzal@ti.com>
> > > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > > > > Reviewed-by: Kevin Hilman <khilman@ti.com>
> > > >
> > > > I realize people may not necessarily like this, but I think that the
> > > > AM33xx EVM needs its own board file. This is because it really has
> > > > nothing to do with the AM3517EVM. Also, the AM3517EVM depends on
> > > > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on
> > > > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
> >
> > I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
> > except core with omap3. And the SOC is independent of the core selected,
> > there is no dependency between SoC and the core.
> >
> > Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
> > CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
> > compile with different flags either.
> >
>
> But still we do have ARCH_OMAP2, ARCH_OMAP3 and ARCH_OMAP4? And that's where,
> we have issues for adding new devices like AM33xx and TI81xx.
Those will be going away, but doing it has not been done because of the amount
of churn it creates. But if we add #define CONFIG_ARCH_OMAP3 CONFIG_SOC_OMAP3
we can do it piecemeal along with other cleanups.
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter for debugSS module control
@ 2013-03-04 11:35 ` hvaibhav at ti.com
2013-03-14 11:29 ` Hiremath, Vaibhav
0 siblings, 1 reply; 57+ messages in thread
From: hvaibhav at ti.com @ 2013-03-04 11:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Vaibhav Hiremath <hvaibhav@ti.com>
Currently there is no clean mechanism to control debugSS module and
you have to always keep clocks enabled, either,
- By enabling it during boot as part of clk_init function
(post common-clock migration).
Or
- By having HWMOD_INIT_NO_IDLE flag in hwmod data
(Joel submitted patch for AM335x earlier).
Based on the discussion with Kevin H,
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg81771.html
This patch introduces new kernel parameter "omap_debugss_en",
which will allow user to control debugSS module enable/disable
part during boot-time.
In case of OMAP3, the debugSS is part of EMU domain and
is currently controlled by clock tree alone.
In case of OMAP4, the debugSS is part of EMU domain and
is currently controlled by clock tree, as MODULEMODE_SWCTRL
is not defined for hwmod.
In case of AM335x, the debugSS is in wakeup domain and is currently
controlled through hwmod alone. Currently we keep it always enabled.
Testing:
- Tested on AM335x based EVM and BeagleBone platform
As required, without this flag the debugSS module will be disabled
during kernel boot.
OMAP (2/3/4) may require some changes from clock/hwmod perspective
in order to use this new parameter.
I am still looking into OMAP spec and this RFC version of patch-series
is to get comments or opinion from list.
Vaibhav Hiremath (3):
ARM: AM33XX: clock: Add debugSS clock nodes to clock tree
ARM: AM33XX: hwmod: Add hwmod data for debugSS
ARM: OMAP2+: Add command line parameter for debugSS module control
Documentation/kernel-parameters.txt | 3 +
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/cclock33xx_data.c | 47 +++++++++++++++--
arch/arm/mach-omap2/debugss.c | 80 ++++++++++++++++++++++++++++
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 69 ++++++++++++++++--------
5 files changed, 173 insertions(+), 28 deletions(-)
create mode 100644 arch/arm/mach-omap2/debugss.c
^ permalink raw reply [flat|nested] 57+ messages in thread* [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter for debugSS module control
2013-03-04 11:35 ` [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter for debugSS module control hvaibhav at ti.com
@ 2013-03-14 11:29 ` Hiremath, Vaibhav
2013-04-08 17:30 ` Tony Lindgren
0 siblings, 1 reply; 57+ messages in thread
From: Hiremath, Vaibhav @ 2013-03-14 11:29 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Hiremath, Vaibhav
> Sent: Monday, March 04, 2013 5:06 PM
> To: linux-omap at vger.kernel.org
> Cc: tony at atomide.com; khilman at linaro.org; paul at pwsan.com; Nayak,
> Rajendra; linux-arm-kernel at lists.infradead.org; Hiremath, Vaibhav
> Subject: [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter for
> debugSS module control
>
> From: Vaibhav Hiremath <hvaibhav@ti.com>
>
> Currently there is no clean mechanism to control debugSS module and
> you have to always keep clocks enabled, either,
>
> - By enabling it during boot as part of clk_init function
> (post common-clock migration).
> Or
> - By having HWMOD_INIT_NO_IDLE flag in hwmod data
> (Joel submitted patch for AM335x earlier).
>
> Based on the discussion with Kevin H,
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg81771.html
>
> This patch introduces new kernel parameter "omap_debugss_en",
> which will allow user to control debugSS module enable/disable
> part during boot-time.
>
> In case of OMAP3, the debugSS is part of EMU domain and
> is currently controlled by clock tree alone.
>
> In case of OMAP4, the debugSS is part of EMU domain and
> is currently controlled by clock tree, as MODULEMODE_SWCTRL
> is not defined for hwmod.
>
> In case of AM335x, the debugSS is in wakeup domain and is currently
> controlled through hwmod alone. Currently we keep it always enabled.
>
> Testing:
> - Tested on AM335x based EVM and BeagleBone platform
>
> As required, without this flag the debugSS module will be
> disabled
> during kernel boot.
>
> OMAP (2/3/4) may require some changes from clock/hwmod perspective
> in order to use this new parameter.
> I am still looking into OMAP spec and this RFC version of patch-series
> is to get comments or opinion from list.
>
> Vaibhav Hiremath (3):
> ARM: AM33XX: clock: Add debugSS clock nodes to clock tree
> ARM: AM33XX: hwmod: Add hwmod data for debugSS
> ARM: OMAP2+: Add command line parameter for debugSS module control
>
> Documentation/kernel-parameters.txt | 3 +
> arch/arm/mach-omap2/Makefile | 2 +-
> arch/arm/mach-omap2/cclock33xx_data.c | 47 +++++++++++++++--
> arch/arm/mach-omap2/debugss.c | 80
> ++++++++++++++++++++++++++++
> arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 69 ++++++++++++++++----
> ----
> 5 files changed, 173 insertions(+), 28 deletions(-)
> create mode 100644 arch/arm/mach-omap2/debugss.c
Kevin/Tony,
Any comments or input on this patch series?
Thanks,
Vaibhav
^ permalink raw reply [flat|nested] 57+ messages in thread
* [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter for debugSS module control
2013-03-14 11:29 ` Hiremath, Vaibhav
@ 2013-04-08 17:30 ` Tony Lindgren
2013-04-09 8:11 ` Hiremath, Vaibhav
0 siblings, 1 reply; 57+ messages in thread
From: Tony Lindgren @ 2013-04-08 17:30 UTC (permalink / raw)
To: linux-arm-kernel
* Hiremath, Vaibhav <hvaibhav@ti.com> [130314 04:33]:
> > From: Hiremath, Vaibhav
> > This patch introduces new kernel parameter "omap_debugss_en",
> > which will allow user to control debugSS module enable/disable
> > part during boot-time.
> >
> > In case of OMAP3, the debugSS is part of EMU domain and
> > is currently controlled by clock tree alone.
> >
> > In case of OMAP4, the debugSS is part of EMU domain and
> > is currently controlled by clock tree, as MODULEMODE_SWCTRL
> > is not defined for hwmod.
> >
> > In case of AM335x, the debugSS is in wakeup domain and is currently
> > controlled through hwmod alone. Currently we keep it always enabled.
>
> Any comments or input on this patch series?
No comments on adding the clocks, but the enabling of
them should be just a regular device driver.
Regards,
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread
* [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter for debugSS module control
2013-04-08 17:30 ` Tony Lindgren
@ 2013-04-09 8:11 ` Hiremath, Vaibhav
0 siblings, 0 replies; 57+ messages in thread
From: Hiremath, Vaibhav @ 2013-04-09 8:11 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Monday, April 08, 2013 11:01 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap at vger.kernel.org; khilman at linaro.org; paul at pwsan.com;
> Nayak, Rajendra; linux-arm-kernel at lists.infradead.org
> Subject: Re: [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter
> for debugSS module control
>
> * Hiremath, Vaibhav <hvaibhav@ti.com> [130314 04:33]:
> > > From: Hiremath, Vaibhav
> > > This patch introduces new kernel parameter "omap_debugss_en",
> > > which will allow user to control debugSS module enable/disable
> > > part during boot-time.
> > >
> > > In case of OMAP3, the debugSS is part of EMU domain and
> > > is currently controlled by clock tree alone.
> > >
> > > In case of OMAP4, the debugSS is part of EMU domain and
> > > is currently controlled by clock tree, as MODULEMODE_SWCTRL
> > > is not defined for hwmod.
> > >
> > > In case of AM335x, the debugSS is in wakeup domain and is currently
> > > controlled through hwmod alone. Currently we keep it always
> enabled.
> >
> > Any comments or input on this patch series?
>
> No comments on adding the clocks, but the enabling of
> them should be just a regular device driver.
>
Thanks for review, on this patch I will add your Reviewed-by line on next version
Of the patch-series.
I have just responded my comment to the other mail on this, and based on
Your response we can conclude.
Thanks,
Vaibhav
.
^ permalink raw reply [flat|nested] 57+ messages in thread
* [RFC PATCH 1/3] ARM: AM33XX: clock: Add debugSS clock nodes to clock tree
@ 2013-03-04 11:35 ` hvaibhav at ti.com
2013-05-29 19:07 ` Paul Walmsley
0 siblings, 1 reply; 57+ messages in thread
From: hvaibhav at ti.com @ 2013-03-04 11:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Vaibhav Hiremath <hvaibhav@ti.com>
Represent debugSS clock interface as provided in
CM_WKUP_DEBUGSS_CLKCTRL register, which includes,
- Clock gate for optional DEBUG_CLKA and DBGSYSCLK
- Clock Mux for TRC_PMD and STM_PMD
- Clock divider for STM and TPIU
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/cclock33xx_data.c | 47 +++++++++++++++++++++++++++++---
1 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c
index 3d5a0e5..12db88c 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -422,15 +422,11 @@ DEFINE_STRUCT_CLK(smartreflex1_fck, dpll_core_ck_parents, clk_ops_null);
* - Driver code is not yet migrated to use hwmod/runtime pm
* - Modules outside kernel access (to disable them by default)
*
- * - debugss
* - mmu (gfx domain)
* - cefuse
* - usbotg_fck (its additional clock and not really a modulemode)
* - ieee5000
*/
-DEFINE_CLK_GATE(debugss_ick, "dpll_core_m4_ck", &dpll_core_m4_ck, 0x0,
- AM33XX_CM_WKUP_DEBUGSS_CLKCTRL, AM33XX_MODULEMODE_SWCTRL_SHIFT,
- 0x0, NULL);
DEFINE_CLK_GATE(mmu_fck, "dpll_core_m4_ck", &dpll_core_m4_ck, 0x0,
AM33XX_CM_GFX_MMUDATA_CLKCTRL, AM33XX_MODULEMODE_SWCTRL_SHIFT,
@@ -833,6 +829,42 @@ static struct clk_hw_omap wdt1_fck_hw = {
DEFINE_STRUCT_CLK(wdt1_fck, wdt_ck_parents, gpio_fck_ops);
/*
+ * debugss optional clocks
+ */
+DEFINE_CLK_GATE(dbg_sysclk_ck, "sys_clkin_ck", &sys_clkin_ck,
+ 0x0, AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
+ AM33XX_OPTFCLKEN_DBGSYSCLK_SHIFT, 0x0, NULL);
+
+DEFINE_CLK_GATE(dbg_clka_ck, "dpll_core_m4_ck", &dpll_core_m4_ck,
+ 0x0, AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
+ AM33XX_OPTCLK_DEBUG_CLKA_SHIFT, 0x0, NULL);
+
+static const char *stm_pmd_clock_mux_ck_parents[] = {
+ "dbg_sysclk_ck", "dbg_clka_ck",
+};
+
+DEFINE_CLK_MUX(stm_pmd_clock_mux_ck, stm_pmd_clock_mux_ck_parents, NULL, 0x0,
+ AM33XX_CM_WKUP_DEBUGSS_CLKCTRL, AM33XX_STM_PMD_CLKSEL_SHIFT,
+ AM33XX_STM_PMD_CLKSEL_WIDTH, 0x0, NULL);
+
+DEFINE_CLK_MUX(trace_pmd_clk_mux_ck, stm_pmd_clock_mux_ck_parents, NULL, 0x0,
+ AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
+ AM33XX_TRC_PMD_CLKSEL_SHIFT,
+ AM33XX_TRC_PMD_CLKSEL_WIDTH, 0x0, NULL);
+
+DEFINE_CLK_DIVIDER(stm_clk_div_ck, "stm_pmd_clock_mux_ck",
+ &stm_pmd_clock_mux_ck, 0x0, AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
+ AM33XX_STM_PMD_CLKDIVSEL_SHIFT,
+ AM33XX_STM_PMD_CLKDIVSEL_WIDTH, CLK_DIVIDER_POWER_OF_TWO,
+ NULL);
+
+DEFINE_CLK_DIVIDER(trace_clk_div_ck, "trace_pmd_clk_mux_ck",
+ &trace_pmd_clk_mux_ck, 0x0, AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
+ AM33XX_TRC_PMD_CLKDIVSEL_SHIFT,
+ AM33XX_TRC_PMD_CLKDIVSEL_WIDTH, CLK_DIVIDER_POWER_OF_TWO,
+ NULL);
+
+/*
* clkdev
*/
static struct omap_clk am33xx_clks[] = {
@@ -869,7 +901,6 @@ static struct omap_clk am33xx_clks[] = {
CLK("481cc000.d_can", NULL, &dcan0_fck, CK_AM33XX),
CLK(NULL, "dcan1_fck", &dcan1_fck, CK_AM33XX),
CLK("481d0000.d_can", NULL, &dcan1_fck, CK_AM33XX),
- CLK(NULL, "debugss_ick", &debugss_ick, CK_AM33XX),
CLK(NULL, "pruss_ocp_gclk", &pruss_ocp_gclk, CK_AM33XX),
CLK(NULL, "mcasp0_fck", &mcasp0_fck, CK_AM33XX),
CLK(NULL, "mcasp1_fck", &mcasp1_fck, CK_AM33XX),
@@ -910,6 +941,12 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, "clkout2_div_ck", &clkout2_div_ck, CK_AM33XX),
CLK(NULL, "timer_32k_ck", &clkdiv32k_ick, CK_AM33XX),
CLK(NULL, "timer_sys_ck", &sys_clkin_ck, CK_AM33XX),
+ CLK(NULL, "dbg_sysclk_ck", &dbg_sysclk_ck, CK_AM33XX),
+ CLK(NULL, "dbg_clka_ck", &dbg_clka_ck, CK_AM33XX),
+ CLK(NULL, "stm_pmd_clock_mux_ck", &stm_pmd_clock_mux_ck, CK_AM33XX),
+ CLK(NULL, "trace_pmd_clk_mux_ck", &trace_pmd_clk_mux_ck, CK_AM33XX),
+ CLK(NULL, "stm_clk_div_ck", &stm_clk_div_ck, CK_AM33XX),
+ CLK(NULL, "trace_clk_div_ck", &trace_clk_div_ck, CK_AM33XX),
};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 57+ messages in thread* [RFC PATCH 1/3] ARM: AM33XX: clock: Add debugSS clock nodes to clock tree
2013-03-04 11:35 ` [RFC PATCH 1/3] ARM: AM33XX: clock: Add debugSS clock nodes to clock tree hvaibhav at ti.com
@ 2013-05-29 19:07 ` Paul Walmsley
0 siblings, 0 replies; 57+ messages in thread
From: Paul Walmsley @ 2013-05-29 19:07 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 4 Mar 2013, hvaibhav at ti.com wrote:
> From: Vaibhav Hiremath <hvaibhav@ti.com>
>
> Represent debugSS clock interface as provided in
> CM_WKUP_DEBUGSS_CLKCTRL register, which includes,
> - Clock gate for optional DEBUG_CLKA and DBGSYSCLK
> - Clock Mux for TRC_PMD and STM_PMD
> - Clock divider for STM and TPIU
>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Cc: Kevin Hilman <khilman@linaro.org>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
based on a quick glance.
- Paul
^ permalink raw reply [flat|nested] 57+ messages in thread
* [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for debugSS module control
@ 2013-03-04 11:35 ` hvaibhav at ti.com
2013-04-08 17:29 ` Tony Lindgren
0 siblings, 1 reply; 57+ messages in thread
From: hvaibhav at ti.com @ 2013-03-04 11:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Vaibhav Hiremath <hvaibhav@ti.com>
Currently there is no clean mechanism to control debugSS module and
you have to always keep clocks enabled, either,
- By enabling it during boot as part of clk_init function.
Or
- By having HWMOD_INIT_NO_IDLE flag in hwmod data.
Based on the discussion,
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg81771.html
This patch introduces new kernel parameter "omap_debugss_en",
which will allow user to control debugSS module enable/disable
part during boot-time.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
---
Tested on
- AM335x based EVM and BeagleBone platforms
Documentation/kernel-parameters.txt | 3 +
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/debugss.c | 80 +++++++++++++++++++++++++++++++++++
3 files changed, 84 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/debugss.c
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 6c72381..bf1c822 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2051,6 +2051,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
For example, to override I2C bus2:
omap_mux=i2c2_scl.i2c2_scl=0x100,i2c2_sda.i2c2_sda=0x100
+ omap_debugss_en [OMAP] Enable Debug Sub-System module required
+ for JTAG debugging.
+
oprofile.timer= [HW]
Use timer interrupt instead of performance counters
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d1156cf..aaf5cc2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -5,7 +5,7 @@
# Common support
obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o gpmc.o timer.o pm.o \
common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \
- omap_device.o sram.o
+ omap_device.o sram.o debugss.o
omap-2-3-common = irq.o
hwmod-common = omap_hwmod.o \
diff --git a/arch/arm/mach-omap2/debugss.c b/arch/arm/mach-omap2/debugss.c
new file mode 100644
index 0000000..b45bf2c
--- /dev/null
+++ b/arch/arm/mach-omap2/debugss.c
@@ -0,0 +1,80 @@
+/*
+ * debugss.c: Debug Sus-System related code goes in here
+ *
+ * Copyright (C) {2013} Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is automatically generated from the AM33XX hardware databases.
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/init.h>
+#include <linux/err.h>
+#include <linux/clk.h>
+
+#include "omap_hwmod.h"
+
+static bool is_debugss_en;
+
+/**
+ * omap_debugss_en - Enable debugss clock/module based on user config
+ *
+ * During kernel bootup, omap2 hwmod framework will disable all the
+ * unused/unclaimed modules, which in turn also disables debugss module.
+ * This breaks any further debugging capability provided by HW.
+ *
+ *
+ * Introduce early param which allows user to enable clock/module -
+ *
+ * omap_debugss_en (For all OMAP2 architectures)
+ *
+ * Please note that, with this command-line param, module always remain
+ * enabled.
+ */
+static int __init omap_debugss_en(char *str)
+{
+ is_debugss_en = true;
+ return 0;
+}
+early_param("omap_debugss_en", omap_debugss_en);
+
+static int __init _omap2_debugss_enable(void)
+{
+ const char oh_name[10] = "debugss";
+ struct omap_hwmod *oh;
+ int ret;
+
+ if (is_debugss_en) {
+ struct omap_hwmod_opt_clk *oc;
+ int i;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err("debugss device not found\n");
+ return 0;
+ }
+
+ /* Make sure that hwmod internal data structures are setup */
+ ret = omap_hwmod_setup_one(oh_name);
+ if (ret) {
+ pr_err("failed to setup hwmod for %s\n", oh_name);
+ return 0;
+ }
+ /* Enable optional clocks */
+ for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++) {
+ if (oc->_clk)
+ clk_prepare_enable(oc->_clk);
+ }
+ /* Enable debugss clock/module */
+ omap_hwmod_enable(oh);
+ }
+
+ return 0;
+}
+device_initcall(_omap2_debugss_enable);
--
1.7.0.4
^ permalink raw reply related [flat|nested] 57+ messages in thread* [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for debugSS module control
2013-03-04 11:35 ` [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for debugSS module control hvaibhav at ti.com
@ 2013-04-08 17:29 ` Tony Lindgren
2013-04-09 8:07 ` Hiremath, Vaibhav
0 siblings, 1 reply; 57+ messages in thread
From: Tony Lindgren @ 2013-04-08 17:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
* hvaibhav at ti.com <hvaibhav@ti.com> [130304 03:40]:
> From: Vaibhav Hiremath <hvaibhav@ti.com>
>
> Currently there is no clean mechanism to control debugSS module and
> you have to always keep clocks enabled, either,
>
> - By enabling it during boot as part of clk_init function.
> Or
> - By having HWMOD_INIT_NO_IDLE flag in hwmod data.
>
> Based on the discussion,
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg81771.html
>
> This patch introduces new kernel parameter "omap_debugss_en",
> which will allow user to control debugSS module enable/disable
> part during boot-time.
I suggest you just make this part into a standard DT only
device driver. That way the command line parsing and clock
enabling can happen the normal way.
Is there any reason why this could not be a loadable module?
Regards,
Tony
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Cc: Kevin Hilman <khilman@linaro.org>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Tony Lindgren <tony@atomide.com>
> ---
> Tested on
> - AM335x based EVM and BeagleBone platforms
>
> Documentation/kernel-parameters.txt | 3 +
> arch/arm/mach-omap2/Makefile | 2 +-
> arch/arm/mach-omap2/debugss.c | 80 +++++++++++++++++++++++++++++++++++
> 3 files changed, 84 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/mach-omap2/debugss.c
>
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 6c72381..bf1c822 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2051,6 +2051,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
> For example, to override I2C bus2:
> omap_mux=i2c2_scl.i2c2_scl=0x100,i2c2_sda.i2c2_sda=0x100
>
> + omap_debugss_en [OMAP] Enable Debug Sub-System module required
> + for JTAG debugging.
> +
> oprofile.timer= [HW]
> Use timer interrupt instead of performance counters
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index d1156cf..aaf5cc2 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -5,7 +5,7 @@
> # Common support
> obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o gpmc.o timer.o pm.o \
> common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \
> - omap_device.o sram.o
> + omap_device.o sram.o debugss.o
>
> omap-2-3-common = irq.o
> hwmod-common = omap_hwmod.o \
> diff --git a/arch/arm/mach-omap2/debugss.c b/arch/arm/mach-omap2/debugss.c
> new file mode 100644
> index 0000000..b45bf2c
> --- /dev/null
> +++ b/arch/arm/mach-omap2/debugss.c
> @@ -0,0 +1,80 @@
> +/*
> + * debugss.c: Debug Sus-System related code goes in here
> + *
> + * Copyright (C) {2013} Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This file is automatically generated from the AM33XX hardware databases.
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/err.h>
> +#include <linux/clk.h>
> +
> +#include "omap_hwmod.h"
> +
> +static bool is_debugss_en;
> +
> +/**
> + * omap_debugss_en - Enable debugss clock/module based on user config
> + *
> + * During kernel bootup, omap2 hwmod framework will disable all the
> + * unused/unclaimed modules, which in turn also disables debugss module.
> + * This breaks any further debugging capability provided by HW.
> + *
> + *
> + * Introduce early param which allows user to enable clock/module -
> + *
> + * omap_debugss_en (For all OMAP2 architectures)
> + *
> + * Please note that, with this command-line param, module always remain
> + * enabled.
> + */
> +static int __init omap_debugss_en(char *str)
> +{
> + is_debugss_en = true;
> + return 0;
> +}
> +early_param("omap_debugss_en", omap_debugss_en);
> +
> +static int __init _omap2_debugss_enable(void)
> +{
> + const char oh_name[10] = "debugss";
> + struct omap_hwmod *oh;
> + int ret;
> +
> + if (is_debugss_en) {
> + struct omap_hwmod_opt_clk *oc;
> + int i;
> +
> + oh = omap_hwmod_lookup(oh_name);
> + if (!oh) {
> + pr_err("debugss device not found\n");
> + return 0;
> + }
> +
> + /* Make sure that hwmod internal data structures are setup */
> + ret = omap_hwmod_setup_one(oh_name);
> + if (ret) {
> + pr_err("failed to setup hwmod for %s\n", oh_name);
> + return 0;
> + }
> + /* Enable optional clocks */
> + for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++) {
> + if (oc->_clk)
> + clk_prepare_enable(oc->_clk);
> + }
> + /* Enable debugss clock/module */
> + omap_hwmod_enable(oh);
> + }
> +
> + return 0;
> +}
> +device_initcall(_omap2_debugss_enable);
> --
> 1.7.0.4
>
^ permalink raw reply [flat|nested] 57+ messages in thread* [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for debugSS module control
2013-04-08 17:29 ` Tony Lindgren
@ 2013-04-09 8:07 ` Hiremath, Vaibhav
2013-04-09 16:34 ` Tony Lindgren
0 siblings, 1 reply; 57+ messages in thread
From: Hiremath, Vaibhav @ 2013-04-09 8:07 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Monday, April 08, 2013 11:00 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap at vger.kernel.org; khilman at linaro.org; paul at pwsan.com;
> Nayak, Rajendra; linux-arm-kernel at lists.infradead.org
> Subject: Re: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter
> for debugSS module control
>
> Hi,
>
> * hvaibhav at ti.com <hvaibhav@ti.com> [130304 03:40]:
> > From: Vaibhav Hiremath <hvaibhav@ti.com>
> >
> > Currently there is no clean mechanism to control debugSS module and
> > you have to always keep clocks enabled, either,
> >
> > - By enabling it during boot as part of clk_init function.
> > Or
> > - By having HWMOD_INIT_NO_IDLE flag in hwmod data.
> >
> > Based on the discussion,
> > http://www.mail-archive.com/linux-omap at vger.kernel.org/msg81771.html
> >
> > This patch introduces new kernel parameter "omap_debugss_en",
> > which will allow user to control debugSS module enable/disable
> > part during boot-time.
>
> I suggest you just make this part into a standard DT only
> device driver. That way the command line parsing and clock
> enabling can happen the normal way.
>
That?s good idea, as we are moving towards DT only boot support.
Also, are you suggesting to have both command-line param and DT
Property for this?
> Is there any reason why this could not be a loadable module?
>
Because we want to keep it enabled before late_initcall. As part of late_initcall
Clock/hwmod framework will start disabling unused modules, which will impact the
Debugs as well. Consider the case where this debugss is loaded as a module, the user
Will loose the JTAG connection until the module is loaded; and once module is
Loaded, he has to again re-connect to the debugss.
With only DT option the code will look like below, is this what you also have in your mind -
arch/arm/boot/dts/am33xx.dtsi:
debugss: debugss at 4b000000 {
compatible = "ti,debugss";
ti,hwmods = "debugss";
reg = <0x4b000000 1000000>;
status = "disabled"; /* User need to enable it if he need JTAG connectivity*/
};
arch/arm/mach-omap2/debugss.c:
static int __init _omap2_debugss_enable(void)
{
struct device_node *np;
np = of_find_matching_node(oh_name);
if (!node || ! of_device_is_available()) {
pr_err("debugss device is not found\n");
return -ENODEV;
}
...
hwmod lookup./setup/enable along with optional clock enable.
...
}
device_initcall(_omap2_debugss_enable);
Thanks,
Vaibhav
^ permalink raw reply [flat|nested] 57+ messages in thread* [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for debugSS module control
2013-04-09 8:07 ` Hiremath, Vaibhav
@ 2013-04-09 16:34 ` Tony Lindgren
2013-04-10 5:11 ` Hiremath, Vaibhav
0 siblings, 1 reply; 57+ messages in thread
From: Tony Lindgren @ 2013-04-09 16:34 UTC (permalink / raw)
To: linux-arm-kernel
* Hiremath, Vaibhav <hvaibhav@ti.com> [130409 01:12]:
> > From: Tony Lindgren [mailto:tony at atomide.com]
> >
> > I suggest you just make this part into a standard DT only
> > device driver. That way the command line parsing and clock
> > enabling can happen the normal way.
> >
>
> That?s good idea, as we are moving towards DT only boot support.
> Also, are you suggesting to have both command-line param and DT
> Property for this?
>
>
> > Is there any reason why this could not be a loadable module?
> >
>
> Because we want to keep it enabled before late_initcall. As part of late_initcall
> Clock/hwmod framework will start disabling unused modules, which will impact the
> Debugs as well. Consider the case where this debugss is loaded as a module, the user
> Will loose the JTAG connection until the module is loaded; and once module is
> Loaded, he has to again re-connect to the debugss.
It will get run before late_initcall if compiled in. Sounds
like there are no issues also make it work as a loadable module
as needed.
> With only DT option the code will look like below, is this what you also have in your mind -
>
> arch/arm/boot/dts/am33xx.dtsi:
>
> debugss: debugss at 4b000000 {
> compatible = "ti,debugss";
> ti,hwmods = "debugss";
> reg = <0x4b000000 1000000>;
> status = "disabled"; /* User need to enable it if he need JTAG connectivity*/
> };
>
>
> arch/arm/mach-omap2/debugss.c:
>
> static int __init _omap2_debugss_enable(void)
> {
> struct device_node *np;
>
> np = of_find_matching_node(oh_name);
> if (!node || ! of_device_is_available()) {
> pr_err("debugss device is not found\n");
> return -ENODEV;
> }
> ...
> hwmod lookup./setup/enable along with optional clock enable.
> ...
>
> }
> device_initcall(_omap2_debugss_enable);
It should be all standard device driver stuff. I'd make it just
regular module_platform_driver and only initialize it earlier if
compiled in.
Regards,
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread* [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for debugSS module control
2013-04-09 16:34 ` Tony Lindgren
@ 2013-04-10 5:11 ` Hiremath, Vaibhav
2013-04-10 17:07 ` Tony Lindgren
0 siblings, 1 reply; 57+ messages in thread
From: Hiremath, Vaibhav @ 2013-04-10 5:11 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Tuesday, April 09, 2013 10:05 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap at vger.kernel.org; khilman at linaro.org; paul at pwsan.com;
> Nayak, Rajendra; linux-arm-kernel at lists.infradead.org
> Subject: Re: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter
> for debugSS module control
>
> * Hiremath, Vaibhav <hvaibhav@ti.com> [130409 01:12]:
> > > From: Tony Lindgren [mailto:tony at atomide.com]
> > >
> > > I suggest you just make this part into a standard DT only
> > > device driver. That way the command line parsing and clock
> > > enabling can happen the normal way.
> > >
> >
> > That?s good idea, as we are moving towards DT only boot support.
> > Also, are you suggesting to have both command-line param and DT
> > Property for this?
> >
> >
> > > Is there any reason why this could not be a loadable module?
> > >
> >
> > Because we want to keep it enabled before late_initcall. As part of
> late_initcall
> > Clock/hwmod framework will start disabling unused modules, which will
> impact the
> > Debugs as well. Consider the case where this debugss is loaded as a
> module, the user
> > Will loose the JTAG connection until the module is loaded; and once
> module is
> > Loaded, he has to again re-connect to the debugss.
>
> It will get run before late_initcall if compiled in. Sounds
> like there are no issues also make it work as a loadable module
> as needed.
>
Agreed on making it as a module.
But do you think we should allow it as a loadable module (M) as well,
as user will loose Connectivity to JTAG during boot.
Another perspective here would be, user can insert the module and
Get JTAG connectivity, which also seems ok to me.
Can you also confirm on having command line argument? I think
We can only live with DT based approach, right?
Thanks,
Vaibhav
^ permalink raw reply [flat|nested] 57+ messages in thread
* [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for debugSS module control
2013-04-10 5:11 ` Hiremath, Vaibhav
@ 2013-04-10 17:07 ` Tony Lindgren
0 siblings, 0 replies; 57+ messages in thread
From: Tony Lindgren @ 2013-04-10 17:07 UTC (permalink / raw)
To: linux-arm-kernel
* Hiremath, Vaibhav <hvaibhav@ti.com> [130409 22:16]:
> Agreed on making it as a module.
>
> But do you think we should allow it as a loadable module (M) as well,
> as user will loose Connectivity to JTAG during boot.
> Another perspective here would be, user can insert the module and
> Get JTAG connectivity, which also seems ok to me.
Yes both ways should be doable.
> Can you also confirm on having command line argument? I think
> We can only live with DT based approach, right?
Well I doubt that anybody wants to keep it permanently enabled
because of the power consumption and blocking of PM states, so
an additional cmdline might make sense.
It would be nice to have it most of the time built-in but disable
itself unless something debug is specified in the cmdline.
Maybe the JTAG driver can detect when the cable is connected?
Or maybe that would be only when there's clock coming over
JTAG?
Regards,
Tony
^ permalink raw reply [flat|nested] 57+ messages in thread