| Message ID | 1341566515-22665-1-git-send-email-santosh.shilimkar@ti.com |
|---|---|
| State | New |
| Headers | show |
* Santosh Shilimkar <santosh.shilimkar@ti.com> [120706 02:26]: > Tony, > > Here is the updated series with suggested corrections and generated against > the latest cleanup-part2 at commit ae6df418. The series adds minimal OMAP5 > support. OMAP5430 has a dual core Cortex-A15 based MPU subsystem with 2MB > L2 cache. The SOC has many compatible blocks with OMAP4 SOCS and hence > large part of the peripherals are re-used. Looking good to me, just one cosmetic comment below: > ARM: OMAP: counter-32k: Select the CR register offset using the IP scheme. > ARM: OMAP5: l3: Add l3 error handler support for omap5. > ARM: omap2+: board-generic: clean up the irq data from board file. > ARM: OMAP5: board-generic: Add device tree support. > ARM: OMAP5: Add SMP support. Can you please remove the trailing period from the patch title lines? That's not typically used.. Thanks, Tony
On Fri, Jul 6, 2012 at 6:06 PM, Tony Lindgren <tony@atomide.com> wrote: > > * Santosh Shilimkar <santosh.shilimkar@ti.com> [120706 02:26]: > > Tony, > > > > Here is the updated series with suggested corrections and generated > > against > > the latest cleanup-part2 at commit ae6df418. The series adds minimal > > OMAP5 > > support. OMAP5430 has a dual core Cortex-A15 based MPU subsystem with > > 2MB > > L2 cache. The SOC has many compatible blocks with OMAP4 SOCS and hence > > large part of the peripherals are re-used. > > Looking good to me, just one cosmetic comment below: > Great. > > ARM: OMAP: counter-32k: Select the CR register offset using the IP > > scheme. > > ARM: OMAP5: l3: Add l3 error handler support for omap5. > > ARM: omap2+: board-generic: clean up the irq data from board file. > > ARM: OMAP5: board-generic: Add device tree support. > > ARM: OMAP5: Add SMP support. > > Can you please remove the trailing period from the patch title lines? > That's not typically used.. > I agree. Fixed it and update the branch. Regards, Santosh
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: > From: R Sricharan <r.sricharan@ti.com> > > OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP > architecture. It's a dual core SOC with GIC used for interrupt > handling and with an integrated L2 cache controller. > > OMAP5432 is another variant of OMAP5430, with a > memory controller supporting DDR3 and SATA. > > Patch includes: > - The machine specific headers and sources updates. > - Platform header updates. > - Minimum initialisation support for serial. > - IO table init > > Signed-off-by: R Sricharan <r.sricharan@ti.com> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > --- > arch/arm/mach-omap2/Makefile | 23 ++++++++++--- > arch/arm/mach-omap2/common.c | 24 +++++++++++++ > arch/arm/mach-omap2/common.h | 11 ++++++ > arch/arm/mach-omap2/include/mach/debug-macro.S | 8 ++--- > arch/arm/mach-omap2/io.c | 44 ++++++++++++++++++++++++ > arch/arm/mach-omap2/iomap.h | 27 +++++++++++++++ > arch/arm/mach-omap2/omap_hwmod.c | 2 +- > arch/arm/mach-omap2/prcm-common.h | 2 +- > arch/arm/mach-omap2/prcm.c | 2 +- > arch/arm/plat-omap/include/plat/clkdev_omap.h | 1 + > arch/arm/plat-omap/include/plat/clock.h | 1 + > arch/arm/plat-omap/include/plat/hardware.h | 1 + > arch/arm/plat-omap/include/plat/multi.h | 9 +++++ > arch/arm/plat-omap/include/plat/omap54xx.h | 32 +++++++++++++++++ > arch/arm/plat-omap/include/plat/serial.h | 10 ++++++ > arch/arm/plat-omap/include/plat/uncompress.h | 6 ++++ > arch/arm/plat-omap/sram.c | 11 ++++-- > 17 files changed, 200 insertions(+), 14 deletions(-) > create mode 100644 arch/arm/plat-omap/include/plat/omap54xx.h > > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile > index 240f196..085e171 100644 > --- a/arch/arm/mach-omap2/Makefile > +++ b/arch/arm/mach-omap2/Makefile > @@ -17,6 +17,7 @@ obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common) > obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common) > obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common) > obj-$(CONFIG_SOC_AM33XX) += irq.o $(hwmod-common) > +obj-$(CONFIG_SOC_OMAP5) += prm44xx.o $(hwmod-common) $(secure-common) > > ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) > obj-y += mcbsp.o > @@ -29,8 +30,10 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC) += sdrc.o > > obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o > obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o > -obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o > -obj-$(CONFIG_ARCH_OMAP4) += sleep44xx.o > +omap-4-5-common = omap4-common.o omap-wakeupgen.o \ > + sleep44xx.o > +obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common) > +obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-common) > > plus_sec := $(call as-instr,.arch_extension sec,+sec) > AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec) > @@ -70,6 +73,7 @@ obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o > obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o > obj-$(CONFIG_ARCH_OMAP3) += cpuidle34xx.o > obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o > +obj-$(CONFIG_SOC_OMAP5) += omap-mpuss-lowpower.o > obj-$(CONFIG_ARCH_OMAP4) += cpuidle44xx.o > obj-$(CONFIG_PM_DEBUG) += pm-debug.o > obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o > @@ -85,14 +89,16 @@ endif > endif > > # PRCM > +omap-prcm-4-5-common = prcm.o cminst44xx.o cm44xx.o \ > + prcm_mpu44xx.o prminst44xx.o \ > + vc44xx_data.o vp44xx_data.o > obj-y += prm_common.o > obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o > obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o > obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o > -obj-$(CONFIG_ARCH_OMAP4) += prcm.o cminst44xx.o cm44xx.o > -obj-$(CONFIG_ARCH_OMAP4) += prcm_mpu44xx.o prminst44xx.o > -obj-$(CONFIG_ARCH_OMAP4) += vc44xx_data.o vp44xx_data.o prm44xx.o > obj-$(CONFIG_SOC_AM33XX) += prcm.o prm33xx.o cm33xx.o > +obj-$(CONFIG_ARCH_OMAP4) += $(omap-prcm-4-5-common) prm44xx.o > +obj-$(CONFIG_SOC_OMAP5) += $(omap-prcm-4-5-common) > > # OMAP voltage domains > voltagedomain-common := voltage.o vc.o vp.o > @@ -104,6 +110,7 @@ obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) > obj-$(CONFIG_ARCH_OMAP4) += voltagedomains44xx_data.o > obj-$(CONFIG_SOC_AM33XX) += $(voltagedomain-common) > obj-$(CONFIG_SOC_AM33XX) += voltagedomains33xx_data.o > +obj-$(CONFIG_SOC_OMAP5) += $(voltagedomain-common) > > # OMAP powerdomain framework > powerdomain-common += powerdomain.o powerdomain-common.o > @@ -121,6 +128,8 @@ obj-$(CONFIG_ARCH_OMAP4) += powerdomains44xx_data.o > obj-$(CONFIG_SOC_AM33XX) += $(powerdomain-common) > obj-$(CONFIG_SOC_AM33XX) += powerdomain33xx.o > obj-$(CONFIG_SOC_AM33XX) += powerdomains33xx_data.o > +obj-$(CONFIG_SOC_OMAP5) += $(powerdomain-common) > +obj-$(CONFIG_SOC_OMAP5) += powerdomain44xx.o > > # PRCM clockdomain control > clockdomain-common += clockdomain.o > @@ -139,6 +148,8 @@ obj-$(CONFIG_ARCH_OMAP4) += clockdomains44xx_data.o > obj-$(CONFIG_SOC_AM33XX) += $(clockdomain-common) > obj-$(CONFIG_SOC_AM33XX) += clockdomain33xx.o > obj-$(CONFIG_SOC_AM33XX) += clockdomains33xx_data.o > +obj-$(CONFIG_SOC_OMAP5) += $(clockdomain-common) > +obj-$(CONFIG_SOC_OMAP5) += clockdomain44xx.o > > # Clock framework > obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o > @@ -157,6 +168,8 @@ obj-$(CONFIG_ARCH_OMAP3) += clkt_iclk.o > obj-$(CONFIG_ARCH_OMAP4) += $(clock-common) clock44xx_data.o > obj-$(CONFIG_ARCH_OMAP4) += dpll3xxx.o dpll44xx.o > obj-$(CONFIG_SOC_AM33XX) += $(clock-common) dpll3xxx.o > +obj-$(CONFIG_SOC_OMAP5) += $(clock-common) > +obj-$(CONFIG_SOC_OMAP5) += dpll3xxx.o dpll44xx.o > > # OMAP2 clock rate set data (old "OPP" data) > obj-$(CONFIG_SOC_OMAP2420) += opp2420_data.o > diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c > index 73d2a0b..069f972 100644 > --- a/arch/arm/mach-omap2/common.c > +++ b/arch/arm/mach-omap2/common.c > @@ -178,3 +178,27 @@ void __init omap4_map_io(void) > } > #endif > > +#if defined(CONFIG_SOC_OMAP5) > +static struct omap_globals omap5_globals = { > + .class = OMAP54XX_CLASS, > + .tap = OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE), > + .ctrl = OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE), > + .ctrl_pad = OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE), > + .prm = OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE), > + .cm = OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_AON_BASE), > + .cm2 = OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE), > + .prcm_mpu = OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE), I am not sure whether we had discussed on this before, couldn't find it. Why don't we reuse OMAP4 data here and elsewhere?? > +}; > + > +void __init omap2_set_globals_5xxx(void) > +{ > + omap2_set_globals_tap(&omap5_globals); > + omap2_set_globals_control(&omap5_globals); > + omap2_set_globals_prcm(&omap5_globals); > +} > + > +void __init omap5_map_io(void) > +{ > + omap5_map_common_io(); > +} > +#endif > diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h > index 404f172..399e5bb 100644 > --- a/arch/arm/mach-omap2/common.h > +++ b/arch/arm/mach-omap2/common.h > @@ -115,6 +115,14 @@ static inline int omap_mux_late_init(void) > } > #endif > > +#ifdef CONFIG_SOC_OMAP5 > +extern void omap5_map_common_io(void); > +#else > +static inline void omap5_map_common_io(void) > +{ > +} > +#endif > + > extern void omap2_init_common_infrastructure(void); > > extern struct sys_timer omap2_timer; > @@ -134,6 +142,7 @@ void am35xx_init_early(void); > void ti81xx_init_early(void); > void am33xx_init_early(void); > void omap4430_init_early(void); > +void omap5_init_early(void); > void omap3_init_late(void); /* Do not use this one */ > void omap4430_init_late(void); > void omap2420_init_late(void); > @@ -169,6 +178,7 @@ void omap2_set_globals_242x(void); > void omap2_set_globals_243x(void); > void omap2_set_globals_3xxx(void); > void omap2_set_globals_443x(void); > +void omap2_set_globals_5xxx(void); > void omap2_set_globals_ti81xx(void); > void omap2_set_globals_am33xx(void); > > @@ -188,6 +198,7 @@ void omap243x_map_io(void); > void omap3_map_io(void); > void am33xx_map_io(void); > void omap4_map_io(void); > +void omap5_map_io(void); > void ti81xx_map_io(void); > void omap_barriers_init(void); > > diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S b/arch/arm/mach-omap2/include/mach/debug-macro.S > index d7f844a..93d10de 100644 > --- a/arch/arm/mach-omap2/include/mach/debug-macro.S > +++ b/arch/arm/mach-omap2/include/mach/debug-macro.S > @@ -60,12 +60,12 @@ omap_uart_lsr: .word 0 > beq 23f @ configure OMAP2UART3 > cmp \rp, #OMAP3UART3 @ only on 34xx > beq 33f @ configure OMAP3UART3 > - cmp \rp, #OMAP4UART3 @ only on 44xx > - beq 43f @ configure OMAP4UART3 > + cmp \rp, #OMAP4UART3 @ only on 44xx/54xx > + beq 43f @ configure OMAP4/5UART3 > cmp \rp, #OMAP3UART4 @ only on 36xx > beq 34f @ configure OMAP3UART4 > - cmp \rp, #OMAP4UART4 @ only on 44xx > - beq 44f @ configure OMAP4UART4 > + cmp \rp, #OMAP4UART4 @ only on 44xx/54xx > + beq 44f @ configure OMAP4/5UART4 > cmp \rp, #TI81XXUART1 @ ti81Xx UART offsets different > beq 81f @ configure UART1 > cmp \rp, #TI81XXUART2 @ ti81Xx UART offsets different > diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c > index cb6c11c..8976be9 100644 > --- a/arch/arm/mach-omap2/io.c > +++ b/arch/arm/mach-omap2/io.c > @@ -233,6 +233,35 @@ static struct map_desc omap44xx_io_desc[] __initdata = { > }; > #endif > > +#ifdef CONFIG_SOC_OMAP5 > +static struct map_desc omap54xx_io_desc[] __initdata = { > + { > + .virtual = L3_54XX_VIRT, > + .pfn = __phys_to_pfn(L3_54XX_PHYS), > + .length = L3_54XX_SIZE, > + .type = MT_DEVICE, > + }, > + { > + .virtual = L4_54XX_VIRT, > + .pfn = __phys_to_pfn(L4_54XX_PHYS), > + .length = L4_54XX_SIZE, > + .type = MT_DEVICE, > + }, > + { > + .virtual = L4_WK_54XX_VIRT, > + .pfn = __phys_to_pfn(L4_WK_54XX_PHYS), > + .length = L4_WK_54XX_SIZE, > + .type = MT_DEVICE, > + }, > + { > + .virtual = L4_PER_54XX_VIRT, > + .pfn = __phys_to_pfn(L4_PER_54XX_PHYS), > + .length = L4_PER_54XX_SIZE, > + .type = MT_DEVICE, > + }, > +}; > +#endif > + > #ifdef CONFIG_SOC_OMAP2420 > void __init omap242x_map_common_io(void) > { > @@ -278,6 +307,12 @@ void __init omap44xx_map_common_io(void) > } > #endif > > +#ifdef CONFIG_SOC_OMAP5 > +void __init omap5_map_common_io(void) > +{ > + iotable_init(omap54xx_io_desc, ARRAY_SIZE(omap54xx_io_desc)); > +} > +#endif > /* > * omap2_init_reprogram_sdrc - reprogram SDRC timing parameters > * > @@ -513,6 +548,15 @@ void __init omap4430_init_late(void) > } > #endif > > +#ifdef CONFIG_SOC_OMAP5 > +void __init omap5_init_early(void) > +{ > + omap2_set_globals_5xxx(); > + omap5xxx_check_revision(); > + omap_common_init_early(); > +} > +#endif > + > void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0, > struct omap_sdrc_params *sdrc_cs1) > { > diff --git a/arch/arm/mach-omap2/iomap.h b/arch/arm/mach-omap2/iomap.h > index 80b8892..cce2b65 100644 > --- a/arch/arm/mach-omap2/iomap.h > +++ b/arch/arm/mach-omap2/iomap.h > @@ -1,6 +1,14 @@ > /* > * IO mappings for OMAP2+ > * > + * IO definitions for TI OMAP processors and boards > + * > + * Copied from arch/arm/mach-sa1100/include/mach/io.h > + * Copyright (C) 1997-1999 Russell King > + * > + * Copyright (C) 2009-2012 Texas Instruments > + * Added OMAP4/5 support - Santosh Shilimkar <santosh.shilimkar@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; either version 2 of the License, or (at your > @@ -166,4 +174,23 @@ > /* 0x49000000 --> 0xfb000000 */ > #define L4_ABE_44XX_VIRT (L4_ABE_44XX_PHYS + OMAP2_L4_IO_OFFSET) > #define L4_ABE_44XX_SIZE SZ_1M > +/* > + * ---------------------------------------------------------------------------- > + * Omap5 specific IO mapping > + * ---------------------------------------------------------------------------- > + */ > +#define L3_54XX_PHYS L3_54XX_BASE /* 0x44000000 --> 0xf8000000 */ > +#define L3_54XX_VIRT (L3_54XX_PHYS + OMAP4_L3_IO_OFFSET) > +#define L3_54XX_SIZE SZ_1M > + > +#define L4_54XX_PHYS L4_54XX_BASE /* 0x4a000000 --> 0xfc000000 */ > +#define L4_54XX_VIRT (L4_54XX_PHYS + OMAP2_L4_IO_OFFSET) > +#define L4_54XX_SIZE SZ_4M > + > +#define L4_WK_54XX_PHYS L4_WK_54XX_BASE /* 0x4ae00000 --> 0xfce00000 */ > +#define L4_WK_54XX_VIRT (L4_WK_54XX_PHYS + OMAP2_L4_IO_OFFSET) > +#define L4_WK_54XX_SIZE SZ_2M > > +#define L4_PER_54XX_PHYS L4_PER_54XX_BASE /* 0x48000000 --> 0xfa000000 */ > +#define L4_PER_54XX_VIRT (L4_PER_54XX_PHYS + OMAP2_L4_IO_OFFSET) > +#define L4_PER_54XX_SIZE SZ_4M Ditto. > diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c > index ff76ef1..2ada364 100644 > --- a/arch/arm/mach-omap2/omap_hwmod.c > +++ b/arch/arm/mach-omap2/omap_hwmod.c > @@ -3619,7 +3619,7 @@ void __init omap_hwmod_init(void) > soc_ops.assert_hardreset = _omap2_assert_hardreset; > soc_ops.deassert_hardreset = _omap2_deassert_hardreset; > soc_ops.is_hardreset_asserted = _omap2_is_hardreset_asserted; > - } else if (cpu_is_omap44xx()) { > + } else if (cpu_is_omap44xx() || soc_is_omap54xx()) { > soc_ops.enable_module = _omap4_enable_module; > soc_ops.disable_module = _omap4_disable_module; > soc_ops.wait_target_ready = _omap4_wait_target_ready; > diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h > index 6da3ba4..44485a8 100644 > --- a/arch/arm/mach-omap2/prcm-common.h > +++ b/arch/arm/mach-omap2/prcm-common.h > @@ -416,7 +416,7 @@ extern void __iomem *cm_base; > extern void __iomem *cm2_base; > extern void __iomem *prcm_mpu_base; > > -#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_OMAP5) > +#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) > extern void omap_prm_base_init(void); > extern void omap_cm_base_init(void); > #else > diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c > index 28cbfb2..053e24e 100644 > --- a/arch/arm/mach-omap2/prcm.c > +++ b/arch/arm/mach-omap2/prcm.c > @@ -160,7 +160,7 @@ void __init omap2_set_globals_prcm(struct omap_globals *omap2_globals) > if (omap2_globals->prcm_mpu) > prcm_mpu_base = omap2_globals->prcm_mpu; > > - if (cpu_is_omap44xx()) { > + if (cpu_is_omap44xx() || soc_is_omap54xx()) { > omap_prm_base_init(); > omap_cm_base_init(); > } > diff --git a/arch/arm/plat-omap/include/plat/clkdev_omap.h b/arch/arm/plat-omap/include/plat/clkdev_omap.h > index d0ed8c4..8f0f5f5 100644 > --- a/arch/arm/plat-omap/include/plat/clkdev_omap.h > +++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h > @@ -39,6 +39,7 @@ struct omap_clk { > #define CK_443X (1 << 11) > #define CK_TI816X (1 << 12) > #define CK_446X (1 << 13) > +#define CK_54XX (1 << 14) This is conflicting with AM33XX, you may want to rebase it again, since AM33xx clock tree is already pushed and available in linux-omap/devel-am33xx-part2. > #define CK_1710 (1 << 15) /* 1710 extra for rate selection */ > > > diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h > index 656b986..323bc84 100644 > --- a/arch/arm/plat-omap/include/plat/clock.h > +++ b/arch/arm/plat-omap/include/plat/clock.h > @@ -61,6 +61,7 @@ struct clkops { > #define RATE_IN_4460 (1 << 7) > #define RATE_IN_AM33XX (1 << 8) > #define RATE_IN_TI814X (1 << 9) > +#define RATE_IN_54XX (1 << 10) > > #define RATE_IN_24XX (RATE_IN_242X | RATE_IN_243X) > #define RATE_IN_34XX (RATE_IN_3430ES1 | RATE_IN_3430ES2PLUS) > diff --git a/arch/arm/plat-omap/include/plat/hardware.h b/arch/arm/plat-omap/include/plat/hardware.h > index e897978..ddbde38 100644 > --- a/arch/arm/plat-omap/include/plat/hardware.h > +++ b/arch/arm/plat-omap/include/plat/hardware.h > @@ -288,5 +288,6 @@ > #include <plat/omap44xx.h> > #include <plat/ti81xx.h> > #include <plat/am33xx.h> > +#include <plat/omap54xx.h> > > #endif /* __ASM_ARCH_OMAP_HARDWARE_H */ > diff --git a/arch/arm/plat-omap/include/plat/multi.h b/arch/arm/plat-omap/include/plat/multi.h > index 999ffba..045e320 100644 > --- a/arch/arm/plat-omap/include/plat/multi.h > +++ b/arch/arm/plat-omap/include/plat/multi.h > @@ -99,4 +99,13 @@ > # endif > #endif > > +#ifdef CONFIG_SOC_OMAP5 > +# ifdef OMAP_NAME > +# undef MULTI_OMAP2 > +# define MULTI_OMAP2 > +# else > +# define OMAP_NAME omap5 > +# endif > +#endif > + > #endif /* __PLAT_OMAP_MULTI_H */ > diff --git a/arch/arm/plat-omap/include/plat/omap54xx.h b/arch/arm/plat-omap/include/plat/omap54xx.h > new file mode 100644 > index 0000000..a2582bb > --- /dev/null > +++ b/arch/arm/plat-omap/include/plat/omap54xx.h > @@ -0,0 +1,32 @@ > +/*: > + * Address mappings and base address for OMAP5 interconnects > + * and peripherals. > + * > + * Copyright (C) 2012 Texas Instruments > + * Santosh Shilimkar <santosh.shilimkar@ti.com> > + * Sricharan <r.sricharan@ti.com> > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > +#ifndef __ASM_SOC_OMAP54XX_H > +#define __ASM_SOC_OMAP54XX_H > + > +/* > + * Please place only base defines here and put the rest in device > + * specific headers. > + */ > +#define L4_54XX_BASE 0x4a000000 > +#define L4_WK_54XX_BASE 0x4ae00000 > +#define L4_PER_54XX_BASE 0x48000000 > +#define L3_54XX_BASE 0x44000000 > +#define OMAP54XX_32KSYNCT_BASE 0x4ae04000 > +#define OMAP54XX_CM_CORE_AON_BASE 0x4a004000 > +#define OMAP54XX_CM_CORE_BASE 0x4a008000 > +#define OMAP54XX_PRM_BASE 0x4ae06000 > +#define OMAP54XX_PRCM_MPU_BASE 0x48243000 > +#define OMAP54XX_SCM_BASE 0x4a002000 > +#define OMAP54XX_CTRL_BASE 0x4a002800 > + > +#endif /* __ASM_SOC_OMAP555554XX_H */ > diff --git a/arch/arm/plat-omap/include/plat/serial.h b/arch/arm/plat-omap/include/plat/serial.h > index 28e2d25..65fce44 100644 > --- a/arch/arm/plat-omap/include/plat/serial.h > +++ b/arch/arm/plat-omap/include/plat/serial.h > @@ -63,6 +63,14 @@ > /* AM33XX serial port */ > #define AM33XX_UART1_BASE 0x44E09000 > > +/* OMAP5 serial ports */ > +#define OMAP5_UART1_BASE OMAP2_UART1_BASE > +#define OMAP5_UART2_BASE OMAP2_UART2_BASE > +#define OMAP5_UART3_BASE OMAP4_UART3_BASE > +#define OMAP5_UART4_BASE OMAP4_UART4_BASE > +#define OMAP5_UART5_BASE 0x48066000 > +#define OMAP5_UART6_BASE 0x48068000 > + > /* External port on Zoom2/3 */ > #define ZOOM_UART_BASE 0x10000000 > #define ZOOM_UART_VIRT 0xfa400000 > @@ -97,6 +105,8 @@ > #define TI81XXUART2 82 > #define TI81XXUART3 83 > #define AM33XXUART1 84 > +#define OMAP5UART3 OMAP4UART3 > +#define OMAP5UART4 OMAP4UART4 > #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 ac43233..b8d19a1 100644 > --- a/arch/arm/plat-omap/include/plat/uncompress.h > +++ b/arch/arm/plat-omap/include/plat/uncompress.h > @@ -95,6 +95,9 @@ static inline void flush(void) > _DEBUG_LL_ENTRY(mach, OMAP4_UART##p##_BASE, OMAP_PORT_SHIFT, \ > OMAP4UART##p) > > +#define DEBUG_LL_OMAP5(p, mach) \ > + _DEBUG_LL_ENTRY(mach, OMAP5_UART##p##_BASE, OMAP_PORT_SHIFT, \ > + OMAP5UART##p) > /* Zoom2/3 shift is different for UART1 and external port */ > #define DEBUG_LL_ZOOM(mach) \ > _DEBUG_LL_ENTRY(mach, ZOOM_UART_BASE, ZOOM_PORT_SHIFT, ZOOM_UART) > @@ -177,6 +180,9 @@ static inline void __arch_decomp_setup(unsigned long arch_id) > DEBUG_LL_OMAP4(3, omap_4430sdp); > DEBUG_LL_OMAP4(3, omap4_panda); > > + /* omap5 based boards using UART3 */ > + DEBUG_LL_OMAP5(3, omap5_sevm); > + > /* zoom2/3 external uart */ > DEBUG_LL_ZOOM(omap_zoom2); > DEBUG_LL_ZOOM(omap_zoom3); > diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c > index 70cf825..766181c 100644 > --- a/arch/arm/plat-omap/sram.c > +++ b/arch/arm/plat-omap/sram.c > @@ -6,8 +6,8 @@ > * Copyright (C) 2005 Nokia Corporation > * Written by Tony Lindgren <tony@atomide.com> > * > - * Copyright (C) 2009 Texas Instruments > - * Added OMAP4 support - Santosh Shilimkar <santosh.shilimkar@ti.com> > + * Copyright (C) 2009-2012 Texas Instruments > + * Added OMAP4/5 support - Santosh Shilimkar <santosh.shilimkar@ti.com> > * > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License version 2 as > @@ -44,6 +44,7 @@ > #else > #define OMAP4_SRAM_PUB_PA (OMAP4_SRAM_PA + 0x4000) > #endif > +#define OMAP5_SRAM_PA 0x40300000 > We have mix of such definitions here, for example, "arch/arm/plat-omap/include/plat/sram.h" and now in arch/arm/plat-omap/sram.c here itself. May be right time to clean it up now. Thanks, Vaibhav > #if defined(CONFIG_ARCH_OMAP2PLUS) > #define SRAM_BOOTLOADER_SZ 0x00 > @@ -118,6 +119,9 @@ static void __init omap_detect_sram(void) > } else if (cpu_is_omap44xx()) { > omap_sram_start = OMAP4_SRAM_PUB_PA; > omap_sram_size = 0xa000; /* 40K */ > + } else if (soc_is_omap54xx()) { > + omap_sram_start = OMAP5_SRAM_PA; > + omap_sram_size = SZ_128K; /* 128KB */ > } else { > omap_sram_start = OMAP2_SRAM_PUB_PA; > omap_sram_size = 0x800; /* 2K */ > @@ -132,6 +136,9 @@ static void __init omap_detect_sram(void) > } else if (cpu_is_omap44xx()) { > omap_sram_start = OMAP4_SRAM_PA; > omap_sram_size = 0xe000; /* 56K */ > + } else if (soc_is_omap54xx()) { > + omap_sram_start = OMAP5_SRAM_PA; > + omap_sram_size = SZ_128K; /* 128KB */ > } else { > omap_sram_start = OMAP2_SRAM_PA; > if (cpu_is_omap242x()) >
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: > From: R Sricharan <r.sricharan@ti.com> > > OMAP socs has a legacy and a highlander version of the > 32k sync counter IP. The register offsets vary between the > highlander and the legacy scheme. So use the 'SCHEME' > bits(30-31) of the revision register to distinguish between Just for my understanding, can we get further information on SCHEME bit-fields? What kind of information we have it here. I may need this info to pass on to design team here. Thanks, Vaibhav > the two versions and choose the CR register offset accordingly. > > Signed-off-by: R Sricharan <r.sricharan@ti.com> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > --- > arch/arm/plat-omap/counter_32k.c | 16 +++++++++++++--- > 1 file changed, 13 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c > index 2132c4f..dbf1e03 100644 > --- a/arch/arm/plat-omap/counter_32k.c > +++ b/arch/arm/plat-omap/counter_32k.c > @@ -29,7 +29,10 @@ > #include <plat/clock.h> > > /* OMAP2_32KSYNCNT_CR_OFF: offset of 32ksync counter register */ > -#define OMAP2_32KSYNCNT_CR_OFF 0x10 > +#define OMAP2_32KSYNCNT_REV_OFF 0x0 > +#define OMAP2_32KSYNCNT_REV_SCHEME (0x3 << 30) > +#define OMAP2_32KSYNCNT_CR_OFF_LOW 0x10 > +#define OMAP2_32KSYNCNT_CR_OFF_HIGH 0x30 > > /* > * 32KHz clocksource ... always available, on pretty most chips except > @@ -84,9 +87,16 @@ int __init omap_init_clocksource_32k(void __iomem *vbase) > int ret; > > /* > - * 32k sync Counter register offset is at 0x10 > + * 32k sync Counter IP register offsets vary between the > + * highlander version and the legacy ones. > + * The 'SCHEME' bits(30-31) of the revision register is used > + * to identify the version. > */ > - sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF; > + if (__raw_readl(vbase + OMAP2_32KSYNCNT_REV_OFF) & > + OMAP2_32KSYNCNT_REV_SCHEME) > + sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_HIGH; > + else > + sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_LOW; > > /* > * 120000 rough estimate from the calculations in >
On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath <hvaibhav@ti.com> wrote: > > > > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: > > From: R Sricharan <r.sricharan@ti.com> > > > > OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP > > architecture. It's a dual core SOC with GIC used for interrupt > > handling and with an integrated L2 cache controller. > > > > OMAP5432 is another variant of OMAP5430, with a > > memory controller supporting DDR3 and SATA. > > > > Patch includes: > > - The machine specific headers and sources updates. > > - Platform header updates. > > - Minimum initialisation support for serial. > > - IO table init > > > > Signed-off-by: R Sricharan <r.sricharan@ti.com> > > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > > --- [..] > > > > +#if defined(CONFIG_SOC_OMAP5) > > +static struct omap_globals omap5_globals = { > > + .class = OMAP54XX_CLASS, > > + .tap = OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE), > > + .ctrl = OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE), > > + .ctrl_pad = OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE), > > + .prm = OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE), > > + .cm = OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_AON_BASE), > > + .cm2 = OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE), > > + .prcm_mpu = OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE), > > I am not sure whether we had discussed on this before, couldn't find it. > > Why don't we reuse OMAP4 data here and elsewhere?? > Because data is not same between OMAP4 and OMAP5. Wherever it is same, it is taken care. [..] > > diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c > > index 70cf825..766181c 100644 > > --- a/arch/arm/plat-omap/sram.c > > +++ b/arch/arm/plat-omap/sram.c > > @@ -6,8 +6,8 @@ > > * Copyright (C) 2005 Nokia Corporation > > * Written by Tony Lindgren <tony@atomide.com> > > * > > - * Copyright (C) 2009 Texas Instruments > > - * Added OMAP4 support - Santosh Shilimkar <santosh.shilimkar@ti.com> > > + * Copyright (C) 2009-2012 Texas Instruments > > + * Added OMAP4/5 support - Santosh Shilimkar <santosh.shilimkar@ti.com> > > * > > * This program is free software; you can redistribute it and/or modify > > * it under the terms of the GNU General Public License version 2 as > > @@ -44,6 +44,7 @@ > > #else > > #define OMAP4_SRAM_PUB_PA (OMAP4_SRAM_PA + 0x4000) > > #endif > > +#define OMAP5_SRAM_PA 0x40300000 > > > > We have mix of such definitions here, for example, > > "arch/arm/plat-omap/include/plat/sram.h" > and now in arch/arm/plat-omap/sram.c here itself. > > > May be right time to clean it up now. > Thats because of an interconnect BUG which needed it exported at plat level in case of OMAP4. Regards Santosh
On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath <hvaibhav@ti.com> wrote: > > > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: >> From: R Sricharan <r.sricharan@ti.com> >> >> OMAP socs has a legacy and a highlander version of the >> 32k sync counter IP. The register offsets vary between the >> highlander and the legacy scheme. So use the 'SCHEME' >> bits(30-31) of the revision register to distinguish between > > > Just for my understanding, can we get further information on SCHEME > bit-fields? What kind of information we have it here. > > I may need this info to pass on to design team here. > Sure. You can refer to the OMAP4 TRM for the bit builds. SCHEME bit field tell you difference between a highlander and legacy IP as the patch says. Regards santosh
* Tony Lindgren <tony@atomide.com> [120709 06:17]: > * Vaibhav Hiremath <hvaibhav@ti.com> [120709 01:55]: > > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: > > > --- a/arch/arm/plat-omap/include/plat/clkdev_omap.h > > > +++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h > > > @@ -39,6 +39,7 @@ struct omap_clk { > > > #define CK_443X (1 << 11) > > > #define CK_TI816X (1 << 12) > > > #define CK_446X (1 << 13) > > > +#define CK_54XX (1 << 14) > > > > This is conflicting with AM33XX, you may want to rebase it again, since > > AM33xx clock tree is already pushed and available in > > linux-omap/devel-am33xx-part2. > > Heh these CK_XXXX defines are now running out of the u16 cpu_mask. > > They really should be replaced with SoC specific lists of clocks > rather than bloating the cpu_mask and repeating it for every clock > that's compiled in for 800+ times. > > Below (untested) is what could be done in the short term. > > I wonder if we could #define CK_OMAP_DUMMY 0 that's always set > for non-shared clocks if they only get set in some *_data.c > file in a unique way? > > Paul got any better ideas? Santosh, I suggest you just drop the CK_54XX change from your patches as the clock fwk support will need further patching and is not used yet. > Regards, > > Tony > > > --- a/arch/arm/plat-omap/include/plat/clkdev_omap.h > +++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h > @@ -26,26 +26,29 @@ struct omap_clk { > } > > /* Platform flags for the clkdev-OMAP integration code */ > + > +#ifdef CONFIG_ARCH_OMAP1 > #define CK_310 (1 << 0) > #define CK_7XX (1 << 1) /* 7xx, 850 */ > #define CK_1510 (1 << 2) > #define CK_16XX (1 << 3) /* 16xx, 17xx, 5912 */ > -#define CK_242X (1 << 4) > -#define CK_243X (1 << 5) /* 243x, 253x */ > -#define CK_3430ES1 (1 << 6) /* 34xxES1 only */ > -#define CK_3430ES2PLUS (1 << 7) /* 34xxES2, ES3, non-Sitara 35xx only */ > -#define CK_AM35XX (1 << 9) /* Sitara AM35xx */ > -#define CK_36XX (1 << 10) /* 36xx/37xx-specific clocks */ > -#define CK_443X (1 << 11) > -#define CK_TI816X (1 << 12) > -#define CK_446X (1 << 13) > -#define CK_AM33XX (1 << 14) /* AM33xx specific clocks */ > -#define CK_1710 (1 << 15) /* 1710 extra for rate selection */ > - > +#define CK_1710 (1 << 4) /* 1710 extra for rate selection */ > +#endif > > +#ifdef CONFIG_ARCH_OMAP2PLUS > +#define CK_242X (1 << 0) > +#define CK_243X (1 << 1) /* 243x, 253x */ > +#define CK_3430ES1 (1 << 2) /* 34xxES1 only */ > +#define CK_3430ES2PLUS (1 << 3) /* 34xxES2, ES3, non-Sitara 35xx only */ > +#define CK_AM35XX (1 << 4) /* Sitara AM35xx */ > +#define CK_36XX (1 << 5) /* 36xx/37xx-specific clocks */ > +#define CK_443X (1 << 6) > +#define CK_TI816X (1 << 7) > +#define CK_446X (1 << 8) > +#define CK_AM33XX (1 << 9) /* AM33xx specific clocks */ > #define CK_34XX (CK_3430ES1 | CK_3430ES2PLUS) > #define CK_3XXX (CK_34XX | CK_AM35XX | CK_36XX) > - > +#endif > > #endif > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jul 9, 2012 at 6:55 PM, Tony Lindgren <tony@atomide.com> wrote: > * Tony Lindgren <tony@atomide.com> [120709 06:17]: >> * Vaibhav Hiremath <hvaibhav@ti.com> [120709 01:55]: >> > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: >> > > --- a/arch/arm/plat-omap/include/plat/clkdev_omap.h >> > > +++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h >> > > @@ -39,6 +39,7 @@ struct omap_clk { >> > > #define CK_443X (1 << 11) >> > > #define CK_TI816X (1 << 12) >> > > #define CK_446X (1 << 13) >> > > +#define CK_54XX (1 << 14) >> > >> > This is conflicting with AM33XX, you may want to rebase it again, since >> > AM33xx clock tree is already pushed and available in >> > linux-omap/devel-am33xx-part2. >> >> Heh these CK_XXXX defines are now running out of the u16 cpu_mask. >> >> They really should be replaced with SoC specific lists of clocks >> rather than bloating the cpu_mask and repeating it for every clock >> that's compiled in for 800+ times. >> >> Below (untested) is what could be done in the short term. >> >> I wonder if we could #define CK_OMAP_DUMMY 0 that's always set >> for non-shared clocks if they only get set in some *_data.c >> file in a unique way? >> >> Paul got any better ideas? > > Santosh, I suggest you just drop the CK_54XX change from your patches > as the clock fwk support will need further patching and is not used > yet. > Good idea. Will have a look at it. Regards Santosh
Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > From: R Sricharan <r.sricharan@ti.com> > > OMAP socs has a legacy and a highlander version of the > 32k sync counter IP. The register offsets vary between the > highlander and the legacy scheme. So use the 'SCHEME' > bits(30-31) of the revision register to distinguish between > the two versions and choose the CR register offset accordingly. Do these scheme bits exist on *all* OMAPs? including OMAP1? This driver is used on OMAP1 as well as OMAP2+. The cover letter says this was only build tested on OMAP1 so I suggest this actually be tested on OMAP1 before merging. Kevin > Signed-off-by: R Sricharan <r.sricharan@ti.com> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > --- > arch/arm/plat-omap/counter_32k.c | 16 +++++++++++++--- > 1 file changed, 13 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c > index 2132c4f..dbf1e03 100644 > --- a/arch/arm/plat-omap/counter_32k.c > +++ b/arch/arm/plat-omap/counter_32k.c > @@ -29,7 +29,10 @@ > #include <plat/clock.h> > > /* OMAP2_32KSYNCNT_CR_OFF: offset of 32ksync counter register */ > -#define OMAP2_32KSYNCNT_CR_OFF 0x10 > +#define OMAP2_32KSYNCNT_REV_OFF 0x0 > +#define OMAP2_32KSYNCNT_REV_SCHEME (0x3 << 30) > +#define OMAP2_32KSYNCNT_CR_OFF_LOW 0x10 > +#define OMAP2_32KSYNCNT_CR_OFF_HIGH 0x30 > > /* > * 32KHz clocksource ... always available, on pretty most chips except > @@ -84,9 +87,16 @@ int __init omap_init_clocksource_32k(void __iomem *vbase) > int ret; > > /* > - * 32k sync Counter register offset is at 0x10 > + * 32k sync Counter IP register offsets vary between the > + * highlander version and the legacy ones. > + * The 'SCHEME' bits(30-31) of the revision register is used > + * to identify the version. > */ > - sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF; > + if (__raw_readl(vbase + OMAP2_32KSYNCNT_REV_OFF) & > + OMAP2_32KSYNCNT_REV_SCHEME) > + sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_HIGH; > + else > + sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_LOW; > > /* > * 120000 rough estimate from the calculations in
Hi Kevin, On 07/09/2012 11:47 AM, Kevin Hilman wrote: > Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > >> From: R Sricharan <r.sricharan@ti.com> >> >> OMAP socs has a legacy and a highlander version of the >> 32k sync counter IP. The register offsets vary between the >> highlander and the legacy scheme. So use the 'SCHEME' >> bits(30-31) of the revision register to distinguish between >> the two versions and choose the CR register offset accordingly. > > Do these scheme bits exist on *all* OMAPs? including OMAP1? > > This driver is used on OMAP1 as well as OMAP2+. > > The cover letter says this was only build tested on OMAP1 so I suggest > this actually be tested on OMAP1 before merging. I have tested this on an omap5912 osk. I booted and verified that the offset is good. Santosh, add my tested-by for OMAP1 ... Tested-by: Jon Hunter <jon-hunter@ti.com> Cheers Jon
On 07/09/2012 11:47 AM, Kevin Hilman wrote: > Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > >> From: R Sricharan <r.sricharan@ti.com> >> >> OMAP socs has a legacy and a highlander version of the >> 32k sync counter IP. The register offsets vary between the >> highlander and the legacy scheme. So use the 'SCHEME' >> bits(30-31) of the revision register to distinguish between >> the two versions and choose the CR register offset accordingly. > > Do these scheme bits exist on *all* OMAPs? including OMAP1? By the way, I believe that for early devices only the lower 8-bits were used and the upper bits return 0. For OMAP5912 I read 0x00000010 from the REV register and so this change should be safe for OMAP1 devices. Cheers Jon
On Tue, Jul 10, 2012 at 4:51 AM, Jon Hunter <jon-hunter@ti.com> wrote: > Hi Kevin, > > On 07/09/2012 11:47 AM, Kevin Hilman wrote: >> Santosh Shilimkar <santosh.shilimkar@ti.com> writes: >> >>> From: R Sricharan <r.sricharan@ti.com> >>> >>> OMAP socs has a legacy and a highlander version of the >>> 32k sync counter IP. The register offsets vary between the >>> highlander and the legacy scheme. So use the 'SCHEME' >>> bits(30-31) of the revision register to distinguish between >>> the two versions and choose the CR register offset accordingly. >> >> Do these scheme bits exist on *all* OMAPs? including OMAP1? >> >> This driver is used on OMAP1 as well as OMAP2+. >> >> The cover letter says this was only build tested on OMAP1 so I suggest >> this actually be tested on OMAP1 before merging. > > I have tested this on an omap5912 osk. I booted and verified that the > offset is good. > > Santosh, add my tested-by for OMAP1 ... > > Tested-by: Jon Hunter <jon-hunter@ti.com> > Thanks a lot Jon. I don't have OMAP1 hardware and hence couldn't do boot testing. I have already sent out PULL request to Tony. if he has not already pulled I should be able to update the OMAP1 tested by tag. Regards Santosh
On Mon, Jul 09, 2012 at 16:09:59, Shilimkar, Santosh wrote: > On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath <hvaibhav@ti.com> wrote: > > > > > > > > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: > > > From: R Sricharan <r.sricharan@ti.com> > > > > > > OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP > > > architecture. It's a dual core SOC with GIC used for interrupt > > > handling and with an integrated L2 cache controller. > > > > > > OMAP5432 is another variant of OMAP5430, with a > > > memory controller supporting DDR3 and SATA. > > > > > > Patch includes: > > > - The machine specific headers and sources updates. > > > - Platform header updates. > > > - Minimum initialisation support for serial. > > > - IO table init > > > > > > Signed-off-by: R Sricharan <r.sricharan@ti.com> > > > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > > > --- > > [..] > > > > > > > +#if defined(CONFIG_SOC_OMAP5) > > > +static struct omap_globals omap5_globals = { > > > + .class = OMAP54XX_CLASS, > > > + .tap = OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE), > > > + .ctrl = OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE), > > > + .ctrl_pad = OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE), > > > + .prm = OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE), > > > + .cm = OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_AON_BASE), > > > + .cm2 = OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE), > > > + .prcm_mpu = OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE), > > > > I am not sure whether we had discussed on this before, couldn't find it. > > > > Why don't we reuse OMAP4 data here and elsewhere?? > > > Because data is not same between OMAP4 and OMAP5. > Wherever it is same, it is taken care. > Above most of the base-addresses are same as omap4. And what about clocktree and hwmod? Is it going tobe same as omap4? Or we have separate data generated? > [..] > > > > diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c > > > index 70cf825..766181c 100644 > > > --- a/arch/arm/plat-omap/sram.c > > > +++ b/arch/arm/plat-omap/sram.c > > > @@ -6,8 +6,8 @@ > > > * Copyright (C) 2005 Nokia Corporation > > > * Written by Tony Lindgren <tony@atomide.com> > > > * > > > - * Copyright (C) 2009 Texas Instruments > > > - * Added OMAP4 support - Santosh Shilimkar <santosh.shilimkar@ti.com> > > > + * Copyright (C) 2009-2012 Texas Instruments > > > + * Added OMAP4/5 support - Santosh Shilimkar <santosh.shilimkar@ti.com> > > > * > > > * This program is free software; you can redistribute it and/or modify > > > * it under the terms of the GNU General Public License version 2 as > > > @@ -44,6 +44,7 @@ > > > #else > > > #define OMAP4_SRAM_PUB_PA (OMAP4_SRAM_PA + 0x4000) > > > #endif > > > +#define OMAP5_SRAM_PA 0x40300000 > > > > > > > We have mix of such definitions here, for example, > > > > "arch/arm/plat-omap/include/plat/sram.h" > > and now in arch/arm/plat-omap/sram.c here itself. > > > > > > May be right time to clean it up now. > > > Thats because of an interconnect BUG which needed it exported > at plat level in case of OMAP4. > Not only omap4, but we have 2, 3, 4 and AM33xx definitions present there at plat/sram.h and public PA (SRAM_PUB_PA) address is defined in sram.c file. Thanks, Vaibhav
On Tue, Jul 10, 2012 at 11:27 AM, Hiremath, Vaibhav <hvaibhav@ti.com> wrote: > On Mon, Jul 09, 2012 at 16:09:59, Shilimkar, Santosh wrote: >> On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath <hvaibhav@ti.com> wrote: >> > >> > >> > >> > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: >> > > From: R Sricharan <r.sricharan@ti.com> >> > > >> > > OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP >> > > architecture. It's a dual core SOC with GIC used for interrupt >> > > handling and with an integrated L2 cache controller. >> > > >> > > OMAP5432 is another variant of OMAP5430, with a >> > > memory controller supporting DDR3 and SATA. >> > > >> > > Patch includes: >> > > - The machine specific headers and sources updates. >> > > - Platform header updates. >> > > - Minimum initialisation support for serial. >> > > - IO table init >> > > >> > > Signed-off-by: R Sricharan <r.sricharan@ti.com> >> > > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> >> > > --- >> >> [..] >> >> > > >> > > +#if defined(CONFIG_SOC_OMAP5) >> > > +static struct omap_globals omap5_globals = { >> > > + .class = OMAP54XX_CLASS, >> > > + .tap = OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE), >> > > + .ctrl = OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE), >> > > + .ctrl_pad = OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE), >> > > + .prm = OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE), >> > > + .cm = OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_AON_BASE), >> > > + .cm2 = OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE), >> > > + .prcm_mpu = OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE), >> > >> > I am not sure whether we had discussed on this before, couldn't find it. >> > >> > Why don't we reuse OMAP4 data here and elsewhere?? >> > >> Because data is not same between OMAP4 and OMAP5. >> Wherever it is same, it is taken care. >> > > Above most of the base-addresses are same as omap4. > > And what about clocktree and hwmod? Is it going tobe same as omap4? > Or we have separate data generated? > The data generated is different for OMAP5. Hwmod, powerdomain, clockdomain, muxes. This data is out of the tree now since we are waiting for ES2.0 data which has some differences w.r.t ES1.0. This was discussed in the beginning as part of this series review on the list. > >> [..] >> >> > > diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c >> > > index 70cf825..766181c 100644 >> > > --- a/arch/arm/plat-omap/sram.c >> > > +++ b/arch/arm/plat-omap/sram.c >> > > @@ -6,8 +6,8 @@ >> > > * Copyright (C) 2005 Nokia Corporation >> > > * Written by Tony Lindgren <tony@atomide.com> >> > > * >> > > - * Copyright (C) 2009 Texas Instruments >> > > - * Added OMAP4 support - Santosh Shilimkar <santosh.shilimkar@ti.com> >> > > + * Copyright (C) 2009-2012 Texas Instruments >> > > + * Added OMAP4/5 support - Santosh Shilimkar <santosh.shilimkar@ti.com> >> > > * >> > > * This program is free software; you can redistribute it and/or modify >> > > * it under the terms of the GNU General Public License version 2 as >> > > @@ -44,6 +44,7 @@ >> > > #else >> > > #define OMAP4_SRAM_PUB_PA (OMAP4_SRAM_PA + 0x4000) >> > > #endif >> > > +#define OMAP5_SRAM_PA 0x40300000 >> > > >> > >> > We have mix of such definitions here, for example, >> > >> > "arch/arm/plat-omap/include/plat/sram.h" >> > and now in arch/arm/plat-omap/sram.c here itself. >> > >> > >> > May be right time to clean it up now. >> > >> Thats because of an interconnect BUG which needed it exported >> at plat level in case of OMAP4. >> > > Not only omap4, but we have 2, 3, 4 and AM33xx definitions present there > at plat/sram.h and public PA (SRAM_PUB_PA) address is defined in sram.c file. > I see that now. Infact there is no need for any of those PA's to be defined there except OMAP4 which needs to have that macro available for an errata. I will clean that up once the series is merged. Don't want to introduce any regression in last moment changes. Regards Santosh
On Tue, Jul 10, 2012 at 11:36:15, Shilimkar, Santosh wrote: > On Tue, Jul 10, 2012 at 11:27 AM, Hiremath, Vaibhav <hvaibhav@ti.com> wrote: > > On Mon, Jul 09, 2012 at 16:09:59, Shilimkar, Santosh wrote: > >> On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath <hvaibhav@ti.com> wrote: > >> > > >> > > >> > > >> > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: > >> > > From: R Sricharan <r.sricharan@ti.com> > >> > > > >> > > OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP > >> > > architecture. It's a dual core SOC with GIC used for interrupt > >> > > handling and with an integrated L2 cache controller. > >> > > > >> > > OMAP5432 is another variant of OMAP5430, with a > >> > > memory controller supporting DDR3 and SATA. > >> > > > >> > > Patch includes: > >> > > - The machine specific headers and sources updates. > >> > > - Platform header updates. > >> > > - Minimum initialisation support for serial. > >> > > - IO table init > >> > > > >> > > Signed-off-by: R Sricharan <r.sricharan@ti.com> > >> > > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > >> > > --- > >> > >> [..] > >> > >> > > > >> > > +#if defined(CONFIG_SOC_OMAP5) > >> > > +static struct omap_globals omap5_globals = { > >> > > + .class = OMAP54XX_CLASS, > >> > > + .tap = OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE), > >> > > + .ctrl = OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE), > >> > > + .ctrl_pad = OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE), > >> > > + .prm = OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE), > >> > > + .cm = OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_AON_BASE), > >> > > + .cm2 = OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE), > >> > > + .prcm_mpu = OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE), > >> > > >> > I am not sure whether we had discussed on this before, couldn't find it. > >> > > >> > Why don't we reuse OMAP4 data here and elsewhere?? > >> > > >> Because data is not same between OMAP4 and OMAP5. > >> Wherever it is same, it is taken care. > >> > > > > Above most of the base-addresses are same as omap4. > > > > And what about clocktree and hwmod? Is it going tobe same as omap4? > > Or we have separate data generated? > > > The data generated is different for OMAP5. Hwmod, powerdomain, clockdomain, > muxes. This data is out of the tree now since we are waiting for ES2.0 > data which > has some differences w.r.t ES1.0. Ok, this is useful information. > This was discussed in the beginning > as part of this > series review on the list. > My bad, I missed that discussion, and will refer to archives now. > > > >> [..] > >> > >> > > diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c > >> > > index 70cf825..766181c 100644 > >> > > --- a/arch/arm/plat-omap/sram.c > >> > > +++ b/arch/arm/plat-omap/sram.c > >> > > @@ -6,8 +6,8 @@ > >> > > * Copyright (C) 2005 Nokia Corporation > >> > > * Written by Tony Lindgren <tony@atomide.com> > >> > > * > >> > > - * Copyright (C) 2009 Texas Instruments > >> > > - * Added OMAP4 support - Santosh Shilimkar <santosh.shilimkar@ti.com> > >> > > + * Copyright (C) 2009-2012 Texas Instruments > >> > > + * Added OMAP4/5 support - Santosh Shilimkar <santosh.shilimkar@ti.com> > >> > > * > >> > > * This program is free software; you can redistribute it and/or modify > >> > > * it under the terms of the GNU General Public License version 2 as > >> > > @@ -44,6 +44,7 @@ > >> > > #else > >> > > #define OMAP4_SRAM_PUB_PA (OMAP4_SRAM_PA + 0x4000) > >> > > #endif > >> > > +#define OMAP5_SRAM_PA 0x40300000 > >> > > > >> > > >> > We have mix of such definitions here, for example, > >> > > >> > "arch/arm/plat-omap/include/plat/sram.h" > >> > and now in arch/arm/plat-omap/sram.c here itself. > >> > > >> > > >> > May be right time to clean it up now. > >> > > >> Thats because of an interconnect BUG which needed it exported > >> at plat level in case of OMAP4. > >> > > > > Not only omap4, but we have 2, 3, 4 and AM33xx definitions present there > > at plat/sram.h and public PA (SRAM_PUB_PA) address is defined in sram.c file. > > > I see that now. Infact there is no need for any of those PA's to be defined > there except OMAP4 which needs to have that macro available for an errata. > > I will clean that up once the series is merged. Don't want to introduce any > regression in last moment changes. > I am ok. Thanks, Vaibhav
On Mon, Jul 09, 2012 at 18:41:58, Tony Lindgren wrote: > * Vaibhav Hiremath <hvaibhav@ti.com> [120709 01:55]: > > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: > > > --- a/arch/arm/plat-omap/include/plat/clkdev_omap.h > > > +++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h > > > @@ -39,6 +39,7 @@ struct omap_clk { > > > #define CK_443X (1 << 11) > > > #define CK_TI816X (1 << 12) > > > #define CK_446X (1 << 13) > > > +#define CK_54XX (1 << 14) > > > > This is conflicting with AM33XX, you may want to rebase it again, since > > AM33xx clock tree is already pushed and available in > > linux-omap/devel-am33xx-part2. > > Heh these CK_XXXX defines are now running out of the u16 cpu_mask. > > They really should be replaced with SoC specific lists of clocks > rather than bloating the cpu_mask and repeating it for every clock > that's compiled in for 800+ times. > > Below (untested) is what could be done in the short term. > > I wonder if we could #define CK_OMAP_DUMMY 0 that's always set > for non-shared clocks if they only get set in some *_data.c > file in a unique way? > > Paul got any better ideas? > > Regards, > > Tony > > > --- a/arch/arm/plat-omap/include/plat/clkdev_omap.h > +++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h > @@ -26,26 +26,29 @@ struct omap_clk { > } > > /* Platform flags for the clkdev-OMAP integration code */ > + > +#ifdef CONFIG_ARCH_OMAP1 > #define CK_310 (1 << 0) > #define CK_7XX (1 << 1) /* 7xx, 850 */ > #define CK_1510 (1 << 2) > #define CK_16XX (1 << 3) /* 16xx, 17xx, 5912 */ > -#define CK_242X (1 << 4) > -#define CK_243X (1 << 5) /* 243x, 253x */ > -#define CK_3430ES1 (1 << 6) /* 34xxES1 only */ > -#define CK_3430ES2PLUS (1 << 7) /* 34xxES2, ES3, non-Sitara 35xx only */ > -#define CK_AM35XX (1 << 9) /* Sitara AM35xx */ > -#define CK_36XX (1 << 10) /* 36xx/37xx-specific clocks */ > -#define CK_443X (1 << 11) > -#define CK_TI816X (1 << 12) > -#define CK_446X (1 << 13) > -#define CK_AM33XX (1 << 14) /* AM33xx specific clocks */ > -#define CK_1710 (1 << 15) /* 1710 extra for rate selection */ > - > +#define CK_1710 (1 << 4) /* 1710 extra for rate selection */ > +#endif > > +#ifdef CONFIG_ARCH_OMAP2PLUS > +#define CK_242X (1 << 0) > +#define CK_243X (1 << 1) /* 243x, 253x */ > +#define CK_3430ES1 (1 << 2) /* 34xxES1 only */ > +#define CK_3430ES2PLUS (1 << 3) /* 34xxES2, ES3, non-Sitara 35xx only */ > +#define CK_AM35XX (1 << 4) /* Sitara AM35xx */ > +#define CK_36XX (1 << 5) /* 36xx/37xx-specific clocks */ > +#define CK_443X (1 << 6) > +#define CK_TI816X (1 << 7) > +#define CK_446X (1 << 8) > +#define CK_AM33XX (1 << 9) /* AM33xx specific clocks */ > #define CK_34XX (CK_3430ES1 | CK_3430ES2PLUS) > #define CK_3XXX (CK_34XX | CK_AM35XX | CK_36XX) > - > +#endif > > #endif This also will not scale up in the future and will end up again in the same situation. Just a quick thought, may work here, I looked at the usage of cpu_mask and rates.flag and I believe we can restrict both to given SoC, something like, OMAP34XX -> ES1 ES2PLUS 36XX AM35XX ... OMAP4 -> 443X 446X AM33XX -> AM335X TI816X TI814X ... XYZ... -> ... The proposal would be, To make cpu_mask and rate.flags 32 bit wide and divide it in 16-16 bits - Lower 16 bits => describe SoC it is applicable to Upper 16 bit => describes silicon versions or families Thanks, Vaibhav
On Mon, Jul 09, 2012 at 16:12:15, Shilimkar, Santosh wrote: > On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath <hvaibhav@ti.com> wrote: > > > > > > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: > >> From: R Sricharan <r.sricharan@ti.com> > >> > >> OMAP socs has a legacy and a highlander version of the > >> 32k sync counter IP. The register offsets vary between the > >> highlander and the legacy scheme. So use the 'SCHEME' > >> bits(30-31) of the revision register to distinguish between > > > > > > Just for my understanding, can we get further information on SCHEME > > bit-fields? What kind of information we have it here. > > > > I may need this info to pass on to design team here. > > > Sure. You can refer to the OMAP4 TRM for the bit builds. > SCHEME bit field tell you difference between a highlander > and legacy IP as the patch says. > Santosh, Can you point to the section of OMAP4 TRM? I referred to both Public TRM and internal TRM, but both only did mention "TI internal Data". And as per code, we are not checking any value in 31-30 bit-fields, code just assumes that, non-zero value would be highlander IP. Thanks, Vaibhav
On Tue, Jul 10, 2012 at 12:11 PM, Hiremath, Vaibhav <hvaibhav@ti.com> wrote: > On Mon, Jul 09, 2012 at 16:12:15, Shilimkar, Santosh wrote: >> On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath <hvaibhav@ti.com> wrote: >> > >> > >> > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: >> >> From: R Sricharan <r.sricharan@ti.com> >> >> >> >> OMAP socs has a legacy and a highlander version of the >> >> 32k sync counter IP. The register offsets vary between the >> >> highlander and the legacy scheme. So use the 'SCHEME' >> >> bits(30-31) of the revision register to distinguish between >> > >> > >> > Just for my understanding, can we get further information on SCHEME >> > bit-fields? What kind of information we have it here. >> > >> > I may need this info to pass on to design team here. >> > >> Sure. You can refer to the OMAP4 TRM for the bit builds. >> SCHEME bit field tell you difference between a highlander >> and legacy IP as the patch says. >> > > Santosh, > > Can you point to the section of OMAP4 TRM? > > I referred to both Public TRM and internal TRM, but both only did mention > "TI internal Data". > Last time I refereed the internal TRM version. Public TRM doesn't carry that information for some reason. > And as per code, we are not checking any value in 31-30 bit-fields, code > just assumes that, non-zero value would be highlander IP. > There are only two types of IP's today and hence it will be either 0x0 or 0x1. So that check if just fine. The highlander IP may have more versions but for known OMAPs and upcoming OMAP, this is the only one supported version. Some more information on the SCHEME bit field. ----------------- 31:30 SCHEME Used to distinguish between old scheme and current. RO Read Only 0x0 - LEGACY 0x1 - Highlander 0.8 scheme -------------------------------- Regards Santosh Read 0x1 HL08 Highlander 0.8 scheme
On Tue, Jul 10, 2012 at 12:42:46, Shilimkar, Santosh wrote: > On Tue, Jul 10, 2012 at 12:11 PM, Hiremath, Vaibhav <hvaibhav@ti.com> wrote: > > On Mon, Jul 09, 2012 at 16:12:15, Shilimkar, Santosh wrote: > >> On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath <hvaibhav@ti.com> wrote: > >> > > >> > > >> > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: > >> >> From: R Sricharan <r.sricharan@ti.com> > >> >> > >> >> OMAP socs has a legacy and a highlander version of the > >> >> 32k sync counter IP. The register offsets vary between the > >> >> highlander and the legacy scheme. So use the 'SCHEME' > >> >> bits(30-31) of the revision register to distinguish between > >> > > >> > > >> > Just for my understanding, can we get further information on SCHEME > >> > bit-fields? What kind of information we have it here. > >> > > >> > I may need this info to pass on to design team here. > >> > > >> Sure. You can refer to the OMAP4 TRM for the bit builds. > >> SCHEME bit field tell you difference between a highlander > >> and legacy IP as the patch says. > >> > > > > Santosh, > > > > Can you point to the section of OMAP4 TRM? > > > > I referred to both Public TRM and internal TRM, but both only did mention > > "TI internal Data". > > > Last time I refereed the internal TRM version. Public TRM doesn't > carry that information > for some reason. > > > And as per code, we are not checking any value in 31-30 bit-fields, code > > just assumes that, non-zero value would be highlander IP. > > > There are only two types of IP's today and hence it will be either > 0x0 or 0x1. So that check if just fine. The highlander IP may have > more versions but for known OMAPs and upcoming OMAP, this is > the only one supported version. > > Some more information on the SCHEME bit field. > ----------------- > 31:30 > SCHEME > Used to distinguish between old scheme and current. > > RO Read Only > > 0x0 - LEGACY > > 0x1 - Highlander 0.8 scheme > -------------------------------- Thanks Santosh, This is what I was looking for, may be it is worth to put this information in either commit description of in code-comment. Thanks, Vaibhav
* Hiremath, Vaibhav <hvaibhav@ti.com> [120709 23:30]: > On Mon, Jul 09, 2012 at 18:41:58, Tony Lindgren wrote: > > * Vaibhav Hiremath <hvaibhav@ti.com> [120709 01:55]: > > > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: > > > > --- a/arch/arm/plat-omap/include/plat/clkdev_omap.h > > > > +++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h > > > > @@ -39,6 +39,7 @@ struct omap_clk { > > > > #define CK_443X (1 << 11) > > > > #define CK_TI816X (1 << 12) > > > > #define CK_446X (1 << 13) > > > > +#define CK_54XX (1 << 14) > > > > > > This is conflicting with AM33XX, you may want to rebase it again, since > > > AM33xx clock tree is already pushed and available in > > > linux-omap/devel-am33xx-part2. > > > > Heh these CK_XXXX defines are now running out of the u16 cpu_mask. > > > > They really should be replaced with SoC specific lists of clocks > > rather than bloating the cpu_mask and repeating it for every clock > > that's compiled in for 800+ times. > > > > Below (untested) is what could be done in the short term. > > > > I wonder if we could #define CK_OMAP_DUMMY 0 that's always set > > for non-shared clocks if they only get set in some *_data.c > > file in a unique way? > > > > Paul got any better ideas? ... > This also will not scale up in the future and will end up again in the same > situation. Right that's why we want to get rid of it. > Just a quick thought, may work here, > > I looked at the usage of cpu_mask and rates.flag and I believe we can > restrict both to given SoC, something like, > > OMAP34XX -> > ES1 > ES2PLUS > 36XX > AM35XX > ... > > OMAP4 -> > 443X > 446X > > AM33XX -> > AM335X > TI816X > TI814X > ... > > XYZ... -> > ... > > > The proposal would be, > > To make cpu_mask and rate.flags 32 bit wide and divide it in 16-16 bits - > > Lower 16 bits => describe SoC it is applicable to > Upper 16 bit => describes silicon versions or families No thanks.. We don't want to make it 32 bit and bloat all the compiled in clock even further. Regards, Tony
On Tue, Jul 10, 2012 at 13:48:52, Tony Lindgren wrote: > * Hiremath, Vaibhav <hvaibhav@ti.com> [120709 23:30]: > > On Mon, Jul 09, 2012 at 18:41:58, Tony Lindgren wrote: > > > * Vaibhav Hiremath <hvaibhav@ti.com> [120709 01:55]: > > > > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: > > > > > --- a/arch/arm/plat-omap/include/plat/clkdev_omap.h > > > > > +++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h > > > > > @@ -39,6 +39,7 @@ struct omap_clk { > > > > > #define CK_443X (1 << 11) > > > > > #define CK_TI816X (1 << 12) > > > > > #define CK_446X (1 << 13) > > > > > +#define CK_54XX (1 << 14) > > > > > > > > This is conflicting with AM33XX, you may want to rebase it again, since > > > > AM33xx clock tree is already pushed and available in > > > > linux-omap/devel-am33xx-part2. > > > > > > Heh these CK_XXXX defines are now running out of the u16 cpu_mask. > > > > > > They really should be replaced with SoC specific lists of clocks > > > rather than bloating the cpu_mask and repeating it for every clock > > > that's compiled in for 800+ times. > > > > > > Below (untested) is what could be done in the short term. > > > > > > I wonder if we could #define CK_OMAP_DUMMY 0 that's always set > > > for non-shared clocks if they only get set in some *_data.c > > > file in a unique way? > > > > > > Paul got any better ideas? > ... > > > This also will not scale up in the future and will end up again in the same > > situation. > > Right that's why we want to get rid of it. > > > Just a quick thought, may work here, > > > > I looked at the usage of cpu_mask and rates.flag and I believe we can > > restrict both to given SoC, something like, > > > > OMAP34XX -> > > ES1 > > ES2PLUS > > 36XX > > AM35XX > > ... > > > > OMAP4 -> > > 443X > > 446X > > > > AM33XX -> > > AM335X > > TI816X > > TI814X > > ... > > > > XYZ... -> > > ... > > > > > > The proposal would be, > > > > To make cpu_mask and rate.flags 32 bit wide and divide it in 16-16 bits - > > > > Lower 16 bits => describe SoC it is applicable to > > Upper 16 bit => describes silicon versions or families > > No thanks.. We don't want to make it 32 bit and bloat all the compiled in > clock even further. > In that case, how about just get rid of cpu_mask completely and trust the data passed by clock-tree for clksel dividers? Let clock-tree data handle this, even if in some cases we end up in duplicating data for some clocks?? Thanks, Vaibhav
* Hiremath, Vaibhav <hvaibhav@ti.com> [120710 01:35]: > On Tue, Jul 10, 2012 at 13:48:52, Tony Lindgren wrote: > > > > No thanks.. We don't want to make it 32 bit and bloat all the compiled in > > clock even further. > > > > In that case, how about just get rid of cpu_mask completely and trust the > data passed by clock-tree for clksel dividers? > Let clock-tree data handle this, even if in some cases we end up in > duplicating data for some clocks?? Yes something like that. We already know which clocks need to be registered, so whatever we still use CK_XXXX for should be also initialized in omapxxxx_clk_init() functions. Regards, Tony
Hi On Mon, 9 Jul 2012, Tony Lindgren wrote: > Below (untested) is what could be done in the short term. That's fine with me. Do you want to queue it or do you want me to queue it? > Heh these CK_XXXX defines are now running out of the u16 cpu_mask. > > They really should be replaced with SoC specific lists of clocks > rather than bloating the cpu_mask and repeating it for every clock > that's compiled in for 800+ times. Frankly, an extra 1.6KB -- uncompressed -- is pretty low on my list of bloat concerns for multi-OMAP kernels. If it were up to me, I'd just change it to a u32 and be done with the problem for the foreseeable future. > I wonder if we could #define CK_OMAP_DUMMY 0 that's always set > for non-shared clocks if they only get set in some *_data.c > file in a unique way? > > Paul got any better ideas? Aside from using u32? Not really. As we've discussed in the past, at some point we should convert the clock initialization to using some kind of per-SoC list. But it doesn't seem worth spending too much time on that while the common clock framework conversion is higher priority. - Paul
* Paul Walmsley <paul@pwsan.com> [120815 15:27]: > Hi > > On Mon, 9 Jul 2012, Tony Lindgren wrote: > > > Below (untested) is what could be done in the short term. > > That's fine with me. Do you want to queue it or do you want me to queue > it? Probably best for you to take it along with other related patches. > > Heh these CK_XXXX defines are now running out of the u16 cpu_mask. > > > > They really should be replaced with SoC specific lists of clocks > > rather than bloating the cpu_mask and repeating it for every clock > > that's compiled in for 800+ times. > > Frankly, an extra 1.6KB -- uncompressed -- is pretty low on my list of > bloat concerns for multi-OMAP kernels. If it were up to me, I'd just > change it to a u32 and be done with the problem for the foreseeable > future. And then we're wasting that 1.6KB.. > > I wonder if we could #define CK_OMAP_DUMMY 0 that's always set > > for non-shared clocks if they only get set in some *_data.c > > file in a unique way? > > > > Paul got any better ideas? > > Aside from using u32? Not really. As we've discussed in the past, at > some point we should convert the clock initialization to using some kind > of per-SoC list. But it doesn't seem worth spending too much time on that > while the common clock framework conversion is higher priority. Right, let's do the ifdef else thing then. Regards, Tony
On Thu, Aug 16, 2012 at 03:56:42, Paul Walmsley wrote: > Hi > > On Mon, 9 Jul 2012, Tony Lindgren wrote: > > > Below (untested) is what could be done in the short term. > > That's fine with me. Do you want to queue it or do you want me to queue > it? > > > Heh these CK_XXXX defines are now running out of the u16 cpu_mask. > > > > They really should be replaced with SoC specific lists of clocks > > rather than bloating the cpu_mask and repeating it for every clock > > that's compiled in for 800+ times. > > Frankly, an extra 1.6KB -- uncompressed -- is pretty low on my list of > bloat concerns for multi-OMAP kernels. If it were up to me, I'd just > change it to a u32 and be done with the problem for the foreseeable > future. > > > I wonder if we could #define CK_OMAP_DUMMY 0 that's always set > > for non-shared clocks if they only get set in some *_data.c > > file in a unique way? > > > > Paul got any better ideas? > > Aside from using u32? Not really. As we've discussed in the past, at > some point we should convert the clock initialization to using some kind > of per-SoC list. But it doesn't seem worth spending too much time on that > while the common clock framework conversion is higher priority. > > This reminds me for AM33xx clock-tree migration to common-clock framework, so just wanted to update on this, I have already converted the clock-tree to common-clock fw, on top of Rajendra's repository. Now waiting on Rajendra for his next series... Thanks, Vaibhav
Hi Santosh, I believe the change from cpu_is_xxx() to soc_is_xxx() just for OMAP5 leads to unnecessary confusion, even though soc_is_ is more technically correct. What do you think? regards, -roger On 07/06/2012 12:21 PM, Santosh Shilimkar wrote: > From: R Sricharan <r.sricharan@ti.com> > > Adding the OMAP5 ES1.0, 2.0 and OMAP5432 cpu revision > detection support. > > Signed-off-by: R Sricharan <r.sricharan@ti.com> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > --- > arch/arm/mach-omap2/control.h | 4 ++++ > arch/arm/mach-omap2/id.c | 42 ++++++++++++++++++++++++++++++++- > arch/arm/plat-omap/include/plat/cpu.h | 22 +++++++++++++++-- > 3 files changed, 65 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h > index 295b390..b8cdc85 100644 > --- a/arch/arm/mach-omap2/control.h > +++ b/arch/arm/mach-omap2/control.h > @@ -253,6 +253,10 @@ > /* TI81XX CONTROL_DEVCONF register offsets */ > #define TI81XX_CONTROL_DEVICE_ID (TI81XX_CONTROL_DEVCONF + 0x000) > > +/* OMAP54XX CONTROL STATUS register */ > +#define OMAP5XXX_CONTROL_STATUS 0x134 > +#define OMAP5_DEVICETYPE_MASK (0x7 << 6) > + > /* > * REVISIT: This list of registers is not comprehensive - there are more > * that should be added. > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c > index 37eb95a..40373db 100644 > --- a/arch/arm/mach-omap2/id.c > +++ b/arch/arm/mach-omap2/id.c > @@ -50,6 +50,11 @@ int omap_type(void) > val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS); > } else if (cpu_is_omap44xx()) { > val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS); > + } else if (soc_is_omap54xx()) { > + val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS); > + val &= OMAP5_DEVICETYPE_MASK; > + val >>= 6; > + goto out; > } else { > pr_err("Cannot detect omap type!\n"); > goto out; > @@ -100,7 +105,7 @@ static u16 tap_prod_id; > > void omap_get_die_id(struct omap_die_id *odi) > { > - if (cpu_is_omap44xx()) { > + if (cpu_is_omap44xx() || soc_is_omap54xx()) { > odi->id_0 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_0); > odi->id_1 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_1); > odi->id_2 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_2); > @@ -513,6 +518,41 @@ void __init omap4xxx_check_revision(void) > ((omap_rev() >> 12) & 0xf), ((omap_rev() >> 8) & 0xf)); > } > > +void __init omap5xxx_check_revision(void) > +{ > + u32 idcode; > + u16 hawkeye; > + u8 rev; > + > + idcode = read_tap_reg(OMAP_TAP_IDCODE); > + hawkeye = (idcode >> 12) & 0xffff; > + rev = (idcode >> 28) & 0xff; > + switch (hawkeye) { > + case 0xb942: > + switch (rev) { > + case 0: > + default: > + omap_revision = OMAP5430_REV_ES1_0; > + } > + break; > + > + case 0xb998: > + switch (rev) { > + case 0: > + default: > + omap_revision = OMAP5432_REV_ES1_0; > + } > + break; > + > + default: > + /* Unknown default to latest silicon rev as default*/ > + omap_revision = OMAP5430_REV_ES1_0; > + } > + > + pr_info("OMAP%04x ES%d.0\n", > + omap_rev() >> 16, ((omap_rev() >> 12) & 0xf)); > +} > + > /* > * Set up things for map_io and processor detection later on. Gets called > * pretty much first thing from board init. For multi-omap, this gets > diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h > index 14f050f..e2d911d 100644 > --- a/arch/arm/plat-omap/include/plat/cpu.h > +++ b/arch/arm/plat-omap/include/plat/cpu.h > @@ -9,7 +9,7 @@ > * > * Written by Tony Lindgren <tony.lindgren@nokia.com> > * > - * Added OMAP4 specific defines - Santosh Shilimkar<santosh.shilimkar@ti.com> > + * Added OMAP4/5 specific defines - Santosh Shilimkar<santosh.shilimkar@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 > @@ -70,6 +70,7 @@ unsigned int omap_rev(void); > * cpu_is_omap443x(): True for OMAP4430 > * cpu_is_omap446x(): True for OMAP4460 > * cpu_is_omap447x(): True for OMAP4470 > + * soc_is_omap543x(): True for OMAP5430, OMAP5432 > */ > #define GET_OMAP_CLASS (omap_rev() & 0xff) > > @@ -122,6 +123,7 @@ IS_OMAP_CLASS(24xx, 0x24) > IS_OMAP_CLASS(34xx, 0x34) > IS_OMAP_CLASS(44xx, 0x44) > IS_AM_CLASS(35xx, 0x35) > +IS_OMAP_CLASS(54xx, 0x54) > IS_AM_CLASS(33xx, 0x33) > > IS_TI_CLASS(81xx, 0x81) > @@ -133,6 +135,7 @@ IS_OMAP_SUBCLASS(363x, 0x363) > IS_OMAP_SUBCLASS(443x, 0x443) > IS_OMAP_SUBCLASS(446x, 0x446) > IS_OMAP_SUBCLASS(447x, 0x447) > +IS_OMAP_SUBCLASS(543x, 0x543) > > IS_TI_SUBCLASS(816x, 0x816) > IS_TI_SUBCLASS(814x, 0x814) > @@ -156,6 +159,8 @@ IS_AM_SUBCLASS(335x, 0x335) > #define cpu_is_omap443x() 0 > #define cpu_is_omap446x() 0 > #define cpu_is_omap447x() 0 > +#define soc_is_omap54xx() 0 > +#define soc_is_omap543x() 0 > > #if defined(MULTI_OMAP1) > # if defined(CONFIG_ARCH_OMAP730) > @@ -291,6 +296,7 @@ IS_OMAP_TYPE(3430, 0x3430) > #define cpu_is_omap2430() 0 > #define cpu_is_omap3430() 0 > #define cpu_is_omap3630() 0 > +#define soc_is_omap5430() 0 > > /* > * Whether we have MULTI_OMAP1 or not, we still need to distinguish > @@ -371,11 +377,18 @@ IS_OMAP_TYPE(3430, 0x3430) > # define cpu_is_omap447x() is_omap447x() > # endif > > +# if defined(CONFIG_SOC_OMAP5) > +# undef soc_is_omap54xx > +# undef soc_is_omap543x > +# define soc_is_omap54xx() is_omap54xx() > +# define soc_is_omap543x() is_omap543x() > +#endif > + > /* Macros to detect if we have OMAP1 or OMAP2 */ > #define cpu_class_is_omap1() (cpu_is_omap7xx() || cpu_is_omap15xx() || \ > cpu_is_omap16xx()) > #define cpu_class_is_omap2() (cpu_is_omap24xx() || cpu_is_omap34xx() || \ > - cpu_is_omap44xx()) > + cpu_is_omap44xx() || soc_is_omap54xx()) > > /* Various silicon revisions for omap2 */ > #define OMAP242X_CLASS 0x24200024 > @@ -428,9 +441,14 @@ IS_OMAP_TYPE(3430, 0x3430) > #define OMAP447X_CLASS 0x44700044 > #define OMAP4470_REV_ES1_0 (OMAP447X_CLASS | (0x10 << 8)) > > +#define OMAP54XX_CLASS 0x54000054 > +#define OMAP5430_REV_ES1_0 (OMAP54XX_CLASS | (0x30 << 16) | (0x10 << 8)) > +#define OMAP5432_REV_ES1_0 (OMAP54XX_CLASS | (0x32 << 16) | (0x10 << 8)) > + > void omap2xxx_check_revision(void); > void omap3xxx_check_revision(void); > void omap4xxx_check_revision(void); > +void omap5xxx_check_revision(void); > void omap3xxx_check_features(void); > void ti81xx_check_features(void); > void omap4xxx_check_features(void); >
* Roger Quadros <rogerq@ti.com> [121102 03:05]: > Hi Santosh, > > I believe the change from cpu_is_xxx() to soc_is_xxx() just for OMAP5 > leads to unnecessary confusion, even though soc_is_ is more technically > correct. All of them will be eventually soc_is_xxx() and private to arch/arm/mach-omap2. Regards, Tony
Tony, Here is the updated series with suggested corrections and generated against the latest cleanup-part2 at commit ae6df418. The series adds minimal OMAP5 support. OMAP5430 has a dual core Cortex-A15 based MPU subsystem with 2MB L2 cache. The SOC has many compatible blocks with OMAP4 SOCS and hence large part of the peripherals are re-used. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. BOOT tested: - OMAP4430 SDP - OMAP3430 SDP - OMAP3430 SDP - OMAP5430 EVM with OMAP5 hwmod/PRM?CM data files. Build testd: - OMAP1 only build, OMAP[2/3/4/5] Only builds. I observed one build break for OMAP4 only build on cleanup-part2 at commit ae6df418. Will post a fix for it in a separate patch. The following changes since commit ae6df418a21f3a361c5f9b878e32a8aba4e17692: ARM: OMAP2+: dmtimer: cleanup fclk usage (2012-07-06 01:13:52 -0700) are available in the git repository at: git://github.com/SantoshShilimkar/linux.git for_3.6/omap5_minimal_support for you to fetch changes up to 37f25749505963d0dce52dfacd6b085de2a8dbeb: ARM: Kconfig update to support additional GPIOs in OMAP5 (2012-07-06 14:18:35 +0530) ---------------------------------------------------------------- R Sricharan (11): ARM: OMAP2+: Move stubbed secure_sram_reserve function to a common.c and call it __weak ARM: OMAP: counter-32k: Select the CR register offset using the IP scheme. ARM: OMAP5: id: Add cpu id for ES versions ARM: OMAP5: Add minimal support for OMAP5430 SOC ARM: OMAP5: timer: Add clocksource, clockevent support ARM: OMAP5: gpmc: Update gpmc_init() ARM: OMAP5: l3: Add l3 error handler support for omap5. ARM: omap2+: board-generic: clean up the irq data from board file. ARM: OMAP5: board-generic: Add device tree support. arm/dts: OMAP5: Add omap5 dts files ARM: OMAP5: Add the build support Santosh Shilimkar (2): ARM: OMAP5: Add the WakeupGen IP updates ARM: OMAP5: Add SMP support. Tarun Kanti DebBarma (1): ARM: Kconfig update to support additional GPIOs in OMAP5 .../devicetree/bindings/arm/omap/omap.txt | 3 + arch/arm/Kconfig | 1 + arch/arm/boot/dts/omap5-evm.dts | 20 +++ arch/arm/boot/dts/omap5.dtsi | 184 ++++++++++++++++++++ arch/arm/configs/omap2plus_defconfig | 1 + arch/arm/mach-omap2/Kconfig | 8 +- arch/arm/mach-omap2/Makefile | 24 ++- arch/arm/mach-omap2/board-generic.c | 42 +++-- arch/arm/mach-omap2/common.c | 24 +++ arch/arm/mach-omap2/common.h | 19 +- arch/arm/mach-omap2/control.h | 4 + arch/arm/mach-omap2/devices.c | 2 +- arch/arm/mach-omap2/gpmc.c | 3 +- arch/arm/mach-omap2/id.c | 42 ++++- arch/arm/mach-omap2/include/mach/debug-macro.S | 8 +- arch/arm/mach-omap2/include/mach/omap-wakeupgen.h | 7 + arch/arm/mach-omap2/io.c | 44 +++++ arch/arm/mach-omap2/iomap.h | 27 +++ arch/arm/mach-omap2/irq.c | 13 +- arch/arm/mach-omap2/omap-headsmp.S | 21 +++ arch/arm/mach-omap2/omap-hotplug.c | 24 ++- arch/arm/mach-omap2/omap-smp.c | 52 ++++-- arch/arm/mach-omap2/omap-wakeupgen.c | 114 +++++++++--- arch/arm/mach-omap2/omap4-common.c | 14 ++ arch/arm/mach-omap2/omap4-sar-layout.h | 12 +- arch/arm/mach-omap2/omap_hwmod.c | 2 +- arch/arm/mach-omap2/omap_l3_noc.h | 22 ++- arch/arm/mach-omap2/prcm-common.h | 2 +- arch/arm/mach-omap2/prcm.c | 2 +- arch/arm/mach-omap2/timer.c | 5 + arch/arm/plat-omap/Kconfig | 4 +- arch/arm/plat-omap/common.c | 9 + arch/arm/plat-omap/counter_32k.c | 16 +- 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/cpu.h | 22 ++- arch/arm/plat-omap/include/plat/hardware.h | 1 + arch/arm/plat-omap/include/plat/multi.h | 9 + arch/arm/plat-omap/include/plat/omap-secure.h | 5 - arch/arm/plat-omap/include/plat/omap54xx.h | 32 ++++ arch/arm/plat-omap/include/plat/serial.h | 10 ++ arch/arm/plat-omap/include/plat/uncompress.h | 6 + arch/arm/plat-omap/sram.c | 11 +- 43 files changed, 775 insertions(+), 98 deletions(-) create mode 100644 arch/arm/boot/dts/omap5-evm.dts create mode 100644 arch/arm/boot/dts/omap5.dtsi create mode 100644 arch/arm/plat-omap/include/plat/omap54xx.h