From: R Sricharan <redacted>
omap_secure_ram_reserve_memblock is stubbed for OMAP1,2 only builds using a
ifdef check. But this results in adding CONFIG_ARCH_OMAPxx checks for
future socs that use the real function. So move this to common.c file and
call it __weak.
Signed-off-by: R Sricharan <redacted>
Signed-off-by: Santosh Shilimkar <redacted>
---
arch/arm/plat-omap/common.c | 9 +++++++++
arch/arm/plat-omap/include/plat/omap-secure.h | 5 -----
2 files changed, 9 insertions(+), 5 deletions(-)
From: R Sricharan <redacted>
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.
Signed-off-by: R Sricharan <redacted>
Signed-off-by: Santosh Shilimkar <redacted>
---
arch/arm/plat-omap/counter_32k.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
@@ -115,6 +115,14 @@ static inline int omap_mux_late_init(void)}#endif+#ifdef CONFIG_SOC_OMAP5+externvoidomap5_map_common_io(void);+#else+staticinlinevoidomap5_map_common_io(void)+{+}+#endif+externvoidomap2_init_common_infrastructure(void);externstructsys_timeromap2_timer;
@@ -134,6 +142,7 @@ void am35xx_init_early(void);voidti81xx_init_early(void);voidam33xx_init_early(void);voidomap4430_init_early(void);+voidomap5_init_early(void);voidomap3_init_late(void);/* Do not use this one */voidomap4430_init_late(void);voidomap2420_init_late(void);
@@ -60,12 +60,12 @@ omap_uart_lsr: .word 0beq23f@configureOMAP2UART3cmp\rp,#OMAP3UART3 @ only on 34xxbeq33f@configureOMAP3UART3-cmp\rp,#OMAP4UART3 @ only on 44xx-beq43f@configureOMAP4UART3+cmp\rp,#OMAP4UART3 @ only on 44xx/54xx+beq43f@configureOMAP4/5UART3cmp\rp,#OMAP3UART4 @ only on 36xxbeq34f@configureOMAP3UART4-cmp\rp,#OMAP4UART4 @ only on 44xx-beq44f@configureOMAP4UART4+cmp\rp,#OMAP4UART4 @ only on 44xx/54xx+beq44f@configureOMAP4/5UART4cmp\rp,#TI81XXUART1 @ ti81Xx UART offsets differentbeq81f@configureUART1cmp\rp,#TI81XXUART2 @ ti81Xx UART offsets different
@@ -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 */
@@ -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);
From: R Sricharan <redacted>
GPMC module is the same as in OMAP4.
Just update the base address and irq number.
Signed-off-by: R Sricharan <redacted>
Signed-off-by: Santosh Shilimkar <redacted>
---
arch/arm/mach-omap2/gpmc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
@@ -727,7 +727,8 @@ static int __init gpmc_init(void)ck="gpmc_fck";l=OMAP34XX_GPMC_BASE;gpmc_irq=INT_34XX_GPMC_IRQ;-}elseif(cpu_is_omap44xx()){+}elseif(cpu_is_omap44xx()||soc_is_omap54xx()){+/* Base address and irq number are same for OMAP4/5 */ck="gpmc_ck";l=OMAP44XX_GPMC_BASE;gpmc_irq=OMAP44XX_IRQ_GPMC;
From: R Sricharan <redacted>
The l3 interconnect ip is same for OMAP4 and OMAP5.
So reuse the l3 error handler error code for OMAP5
as well. Also a few targets has been newly added for
OMAP5. So updating the driver for that here.
Signed-off-by: R Sricharan <redacted>
Signed-off-by: Santosh Shilimkar <redacted>
---
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/devices.c | 2 +-
arch/arm/mach-omap2/omap_l3_noc.h | 22 ++++++++++++++++++----
3 files changed, 20 insertions(+), 5 deletions(-)
OMAP4 and OMAP5 share same WakeupGen IP with below few udpates on OMAP5.
- Additional 32 interrupt support is added w.r.t OMAP4 design.
- The AUX CORE boot registers are now made accessible from non-secure SW.
- SAR offset are changed and PTMSYNC* registers are removed from SAR.
Patch updates the WakeupGen code accordingly.
Signed-off-by: R Sricharan <redacted>
Signed-off-by: Santosh Shilimkar <redacted>
---
arch/arm/mach-omap2/include/mach/omap-wakeupgen.h | 7 ++
arch/arm/mach-omap2/omap-hotplug.c | 24 ++++-
arch/arm/mach-omap2/omap-smp.c | 19 +++-
arch/arm/mach-omap2/omap-wakeupgen.c | 114 ++++++++++++++++-----
arch/arm/mach-omap2/omap4-sar-layout.h | 12 ++-
5 files changed, 143 insertions(+), 33 deletions(-)
@@ -35,7 +37,8 @@ int platform_cpu_kill(unsigned int cpu)*/void__refplatform_cpu_die(unsignedintcpu){-unsignedintthis_cpu;+unsignedintboot_cpu=0;+void__iomem*base=omap_get_wakeupgen_base();flush_cache_all();dsb();
@@ -43,16 +46,27 @@ void __ref platform_cpu_die(unsigned int cpu)/**we'rereadyforshutdownnow,sodoit*/-if(omap_modify_auxcoreboot0(0x0,0x200)!=0x0)-pr_err("Secure clear status failed\n");+if(omap_secure_apis_support()){+if(omap_modify_auxcoreboot0(0x0,0x200)!=0x0)+pr_err("Secure clear status failed\n");+}else{+__raw_writel(0,base+OMAP_AUX_CORE_BOOT_0);+}+for(;;){/**Enterintolowpowerstate*/omap4_hotplug_cpu(cpu,PWRDM_POWER_OFF);-this_cpu=smp_processor_id();-if(omap_read_auxcoreboot0()==this_cpu){++if(omap_secure_apis_support())+boot_cpu=omap_read_auxcoreboot0();+else+boot_cpu=+__raw_readl(base+OMAP_AUX_CORE_BOOT_0)>>5;++if(boot_cpu==smp_processor_id()){/**OK,properwakeup,we'redone*/
@@ -160,7 +165,7 @@ static void _wakeupgen_restore_masks(unsigned int cpu){u8i;-for(i=0;i<NR_REG_BANKS;i++)+for(i=0;i<irq_banks;i++)wakeupgen_writel(per_cpu(irqmasks,cpu)[i],i,cpu);}
@@ -168,7 +173,7 @@ static void _wakeupgen_set_all(unsigned int cpu, unsigned int reg){u8i;-for(i=0;i<NR_REG_BANKS;i++)+for(i=0;i<irq_banks;i++)wakeupgen_writel(reg,i,cpu);}
@@ -196,25 +201,14 @@ static void wakeupgen_irqmask_all(unsigned int cpu, unsigned int set)#endif#ifdef CONFIG_CPU_PM-/*-*SaveWakeupGeninterruptcontextinSARBANK3.Restoreisdoneby-*ROMcode.WakeupGenIPisintegratedalongwithGICtomanagethe-*interruptwakeupsfromCPUlowpowerstates.Itmanages-*masking/unmaskingofSharedperipheralinterrupts(SPI).Sothe-*interruptenable/disablecontrolshouldbeinsyncandconsistent-*atWakeupGenandGICsothatinterruptsarenotlost.-*/-staticvoidirq_save_context(void)+staticinlinevoidomap4_irq_save_context(void){u32i,val;if(omap_rev()==OMAP4430_REV_ES1_0)return;-if(!sar_base)-sar_base=omap4_get_sar_ram_base();--for(i=0;i<NR_REG_BANKS;i++){+for(i=0;i<irq_banks;i++){/* Save the CPUx interrupt mask for IRQ 0 to 127 */val=wakeupgen_readl(i,0);sar_writel(val,WAKEUPGENENB_OFFSET_CPU0,i);
@@ -254,6 +248,53 @@ static void irq_save_context(void)val=__raw_readl(sar_base+SAR_BACKUP_STATUS_OFFSET);val|=SAR_BACKUP_STATUS_WAKEUPGEN;__raw_writel(val,sar_base+SAR_BACKUP_STATUS_OFFSET);++}++staticinlinevoidomap5_irq_save_context(void)+{+u32i,val;++for(i=0;i<irq_banks;i++){+/* Save the CPUx interrupt mask for IRQ 0 to 159 */+val=wakeupgen_readl(i,0);+sar_writel(val,OMAP5_WAKEUPGENENB_OFFSET_CPU0,i);+val=wakeupgen_readl(i,1);+sar_writel(val,OMAP5_WAKEUPGENENB_OFFSET_CPU1,i);+sar_writel(0x0,OMAP5_WAKEUPGENENB_SECURE_OFFSET_CPU0,i);+sar_writel(0x0,OMAP5_WAKEUPGENENB_SECURE_OFFSET_CPU1,i);+}++/* Save AuxBoot* registers */+val=__raw_readl(wakeupgen_base+OMAP_AUX_CORE_BOOT_0);+__raw_writel(val,sar_base+OMAP5_AUXCOREBOOT0_OFFSET);+val=__raw_readl(wakeupgen_base+OMAP_AUX_CORE_BOOT_0);+__raw_writel(val,sar_base+OMAP5_AUXCOREBOOT1_OFFSET);++/* Set the Backup Bit Mask status */+val=__raw_readl(sar_base+OMAP5_SAR_BACKUP_STATUS_OFFSET);+val|=SAR_BACKUP_STATUS_WAKEUPGEN;+__raw_writel(val,sar_base+OMAP5_SAR_BACKUP_STATUS_OFFSET);++}++/*+*SaveWakeupGeninterruptcontextinSARBANK3.Restoreisdoneby+*ROMcode.WakeupGenIPisintegratedalongwithGICtomanagethe+*interruptwakeupsfromCPUlowpowerstates.Itmanages+*masking/unmaskingofSharedperipheralinterrupts(SPI).Sothe+*interruptenable/disablecontrolshouldbeinsyncandconsistent+*atWakeupGenandGICsothatinterruptsarenotlost.+*/+staticvoidirq_save_context(void)+{+if(!sar_base)+sar_base=omap4_get_sar_ram_base();++if(soc_is_omap54xx())+omap5_irq_save_context();+else+omap4_irq_save_context();}/*
@@ -336,13 +382,25 @@ static struct notifier_block irq_notifier_block = {staticvoid__initirq_pm_init(void){-cpu_pm_register_notifier(&irq_notifier_block);+/* FIXME: Remove this when MPU OSWR support is added */+if(!soc_is_omap54xx())+cpu_pm_register_notifier(&irq_notifier_block);}#elsestaticvoid__initirq_pm_init(void){}#endif+void__iomem*omap_get_wakeupgen_base(void)+{+returnwakeupgen_base;+}++intomap_secure_apis_support(void)+{+returnomap_secure_apis;+}+/**Initialisethewakeupgenmodule.*/
@@ -358,12 +416,18 @@ int __init omap_wakeupgen_init(void)}/* Static mapping, never released */-wakeupgen_base=ioremap(OMAP44XX_WKUPGEN_BASE,SZ_4K);+wakeupgen_base=ioremap(OMAP_WKUPGEN_BASE,SZ_4K);if(WARN_ON(!wakeupgen_base))return-ENOMEM;+if(cpu_is_omap44xx()){+irq_banks=OMAP4_NR_BANKS;+max_irqs=OMAP4_NR_IRQS;+omap_secure_apis=1;+}+/* Clear all IRQ bitmasks@wakeupGen level */-for(i=0;i<NR_REG_BANKS;i++){+for(i=0;i<irq_banks;i++){wakeupgen_writel(0,i,CPU0_ID);wakeupgen_writel(0,i,CPU1_ID);}
@@ -382,7 +446,7 @@ int __init omap_wakeupgen_init(void)*//* Associate all the IRQs to boot CPU like GIC init does. */-for(i=0;i<NR_IRQS;i++)+for(i=0;i<max_irqs;i++)irq_target_cpu[i]=boot_cpu;irq_hotplug_init();
@@ -19,6 +19,27 @@#include <linux/init.h>__CPUINIT++/*PhysicaladdressneededsinceMMUnotenabledyetonsecondarycore*/+#define AUX_CORE_BOOT0_PA 0x48281800++/*+*OMAP5specificentrypointforsecondaryCPUtojumpfromROM+*code.Thisroutinealsoprovidesaholdingflagintowhich+*secondarycoreishelduntilwe're ready for it to initialise.+*Theprimarycorewillupdatethisflagusingahardware++*registerAuxCoreBoot0.+*/+ENTRY(omap5_secondary_startup)+wait:ldrr2,=AUX_CORE_BOOT0_PA@readfromAuxCoreBoot0+ldrr0,[r2]+movr0,r0,lsr#5+mrcp15,0,r4,c0,c0,5+andr4,r4,#0x0f+cmpr0,r4+bnewait+bsecondary_startup+END(omap5_secondary_startup)/**OMAP4specificentrypointforsecondaryCPUtojumpfromROM*code.Thisroutinealsoprovidesaholdingflagintowhich
@@ -133,7 +139,6 @@ int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)staticvoid__initwakeup_secondary(void){void__iomem*base=omap_get_wakeupgen_base();-/**Writetheaddressofsecondarystartuproutineintothe*AuxCoreBoot1whereROMcodewilljumpandstartexecuting
@@ -162,16 +167,21 @@ static void __init wakeup_secondary(void)*/void__initsmp_init_cpus(void){-unsignedinti,ncores;--/*-*Currentlywecan'tcallioremapherebecause-*SoCdetectionwon'tworkuntilafterinit_early.-*/-scu_base=OMAP2_L4_IO_ADDRESS(OMAP44XX_SCU_BASE);-BUG_ON(!scu_base);--ncores=scu_get_core_count(scu_base);+unsignedinti=0,ncores=1,cpu_id;++/* Use ARM cpuid check here, as SoC detection will not work so early */+cpu_id=read_cpuid(CPUID_ID)&CPU_MASK;+if(cpu_id==CPU_CORTEX_A9){+/*+*Currentlywecan'tcallioremapherebecause+*SoCdetectionwon'tworkuntilafterinit_early.+*/+scu_base=OMAP2_L4_IO_ADDRESS(OMAP44XX_SCU_BASE);+BUG_ON(!scu_base);+ncores=scu_get_core_count(scu_base);+}elseif(cpu_id==CPU_CORTEX_A15){+ncores=OMAP5_CORE_COUNT;+}/* sanity check */if(ncores>nr_cpu_ids){
@@ -193,6 +203,7 @@ void __init platform_smp_prepare_cpus(unsigned int max_cpus)*InitialisetheSCUandwakeupthesecondarycoreusing*wakeup_secondary().*/-scu_enable(scu_base);+if(scu_base)+scu_enable(scu_base);wakeup_secondary();}
From: R Sricharan <redacted>
Move the irq_match arrays and the irq init functions of OMAP 2,3
and 4 based boards out of board-generic.c file and also rename the
irq init function to match the interrupt controller present in
the SOCs.
This is a preparatory patch to add the OMAP5 evm board's irq init
support with device tree.
Signed-off-by: R Sricharan <redacted>
Signed-off-by: Santosh Shilimkar <redacted>
---
arch/arm/mach-omap2/board-generic.c | 23 ++++++-----------------
arch/arm/mach-omap2/common.h | 6 ++++--
arch/arm/mach-omap2/irq.c | 13 ++++++++++++-
arch/arm/mach-omap2/omap4-common.c | 13 +++++++++++++
4 files changed, 35 insertions(+), 20 deletions(-)
@@ -29,7 +29,7 @@ config ARCH_OMAP2PLUSselectUSE_OFselectPROC_DEVICETREEifPROC_FShelp-"Systems based on OMAP2, OMAP3 or OMAP4"+"Systems based on OMAP2, OMAP3, OMAP4 or OMAP5"endchoice
@@ -150,7 +150,7 @@ config OMAP_32K_TIMERThistimersavespowercomparedtotheOMAP_MPU_TIMER,andhassupportfornotickduringidle.The32KHztimerprovideslessintra-tickresolutionthanOMAP_MPU_TIMER.The32KHztimeris-currentlyonlyavailableforOMAP16XX,24XX,34XXandOMAP4.+currentlyonlyavailableforOMAP16XX,24XX,34XXandOMAP4/5.configOMAP3_L2_AUX_SECURE_SAVE_RESTOREbool"OMAP3 HS/EMU save and restore for L2 AUX control register"
From: Tarun Kanti DebBarma <redacted>
OMAP5 has 8 GPIO banks so that there are 32x8 = 256 GPIOs.
In order for the gpiolib to detect and initialize these
additional GPIOs and other TWL GPIOs, ARCH_NR_GPIO is set
to 512 instead of present 256.
Cc: Santosh Shilimkar <redacted>
Cc: Cousson, Benoit <redacted>
Reported-by: Govindraj.R <redacted>
Tested-by: Govindraj.R <redacted>
Signed-off-by: Tarun Kanti DebBarma <redacted>
Signed-off-by: Santosh Shilimkar <redacted>
---
arch/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
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
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.
quoted
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
@@ -115,6 +115,14 @@ static inline int omap_mux_late_init(void)}#endif+#ifdef CONFIG_SOC_OMAP5+externvoidomap5_map_common_io(void);+#else+staticinlinevoidomap5_map_common_io(void)+{+}+#endif+externvoidomap2_init_common_infrastructure(void);externstructsys_timeromap2_timer;
@@ -134,6 +142,7 @@ void am35xx_init_early(void);voidti81xx_init_early(void);voidam33xx_init_early(void);voidomap4430_init_early(void);+voidomap5_init_early(void);voidomap3_init_late(void);/* Do not use this one */voidomap4430_init_late(void);voidomap2420_init_late(void);
@@ -60,12 +60,12 @@ omap_uart_lsr: .word 0beq23f@configureOMAP2UART3cmp\rp,#OMAP3UART3 @ only on 34xxbeq33f@configureOMAP3UART3-cmp\rp,#OMAP4UART3 @ only on 44xx-beq43f@configureOMAP4UART3+cmp\rp,#OMAP4UART3 @ only on 44xx/54xx+beq43f@configureOMAP4/5UART3cmp\rp,#OMAP3UART4 @ only on 36xxbeq34f@configureOMAP3UART4-cmp\rp,#OMAP4UART4 @ only on 44xx-beq44f@configureOMAP4UART4+cmp\rp,#OMAP4UART4 @ only on 44xx/54xx+beq44f@configureOMAP4/5UART4cmp\rp,#TI81XXUART1 @ ti81Xx UART offsets differentbeq81f@configureUART1cmp\rp,#TI81XXUART2 @ ti81Xx UART offsets different
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.
quoted hunk
#define CK_1710 (1 << 15) /* 1710 extra for rate selection */
@@ -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 */
@@ -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);
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
From: R Sricharan <redacted>
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
quoted hunk
the two versions and choose the CR register offset accordingly.
Signed-off-by: R Sricharan <redacted>
Signed-off-by: Santosh Shilimkar <redacted>
---
arch/arm/plat-omap/counter_32k.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath [off-list ref] wrote:
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
quoted
From: R Sricharan <redacted>
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 <redacted>
Signed-off-by: Santosh Shilimkar <redacted>
---
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 [off-list ref] wrote:
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
quoted
From: R Sricharan <redacted>
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
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
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.
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
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
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.
I dropped the CK_54XX and RATE hunks from the patch. Updated
patch below for the record.
Regards
Santosh
-->>
From 05e152c76a1efaa3165afecf5acf535c8283f386 Mon Sep 17 00:00:00 2001
From: R Sricharan <redacted>
Date: Tue, 5 Jun 2012 16:21:32 +0530
Subject: [PATCH 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP
architecture. It's a dual core SOC with GIC used for interrupt
handling and with an integrated L2 cache controller.
OMAP5432 is another variant of OMAP5430, with a
memory controller supporting DDR3 and SATA.
Patch includes:
- The machine specific headers and sources updates.
- Platform header updates.
- Minimum initialisation support for serial.
- IO table init
Signed-off-by: R Sricharan <redacted>
Signed-off-by: Santosh Shilimkar <redacted>
---
arch/arm/mach-omap2/Makefile | 23 ++++++++++---
arch/arm/mach-omap2/common.c | 24 +++++++++++++
arch/arm/mach-omap2/common.h | 11 ++++++
arch/arm/mach-omap2/include/mach/debug-macro.S | 8 ++---
arch/arm/mach-omap2/io.c | 44 ++++++++++++++++++++++++
arch/arm/mach-omap2/iomap.h | 27 +++++++++++++++
arch/arm/mach-omap2/omap_hwmod.c | 2 +-
arch/arm/mach-omap2/prcm-common.h | 2 +-
arch/arm/mach-omap2/prcm.c | 2 +-
arch/arm/plat-omap/include/plat/hardware.h | 1 +
arch/arm/plat-omap/include/plat/multi.h | 9 +++++
arch/arm/plat-omap/include/plat/omap54xx.h | 32 +++++++++++++++++
arch/arm/plat-omap/include/plat/serial.h | 10 ++++++
arch/arm/plat-omap/include/plat/uncompress.h | 6 ++++
arch/arm/plat-omap/sram.c | 11 ++++--
15 files changed, 198 insertions(+), 14 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/omap54xx.h
@@ -115,6 +115,14 @@ static inline int omap_mux_late_init(void)}#endif+#ifdef CONFIG_SOC_OMAP5+externvoidomap5_map_common_io(void);+#else+staticinlinevoidomap5_map_common_io(void)+{+}+#endif+externvoidomap2_init_common_infrastructure(void);externstructsys_timeromap2_timer;
@@ -134,6 +142,7 @@ void am35xx_init_early(void);voidti81xx_init_early(void);voidam33xx_init_early(void);voidomap4430_init_early(void);+voidomap5_init_early(void);voidomap3_init_late(void);/* Do not use this one */voidomap4430_init_late(void);voidomap2420_init_late(void);
@@ -60,12 +60,12 @@ omap_uart_lsr: .word 0beq23f@configureOMAP2UART3cmp\rp,#OMAP3UART3 @ only on 34xxbeq33f@configureOMAP3UART3-cmp\rp,#OMAP4UART3 @ only on 44xx-beq43f@configureOMAP4UART3+cmp\rp,#OMAP4UART3 @ only on 44xx/54xx+beq43f@configureOMAP4/5UART3cmp\rp,#OMAP3UART4 @ only on 36xxbeq34f@configureOMAP3UART4-cmp\rp,#OMAP4UART4 @ only on 44xx-beq44f@configureOMAP4UART4+cmp\rp,#OMAP4UART4 @ only on 44xx/54xx+beq44f@configureOMAP4/5UART4cmp\rp,#TI81XXUART1 @ ti81Xx UART offsets differentbeq81f@configureUART1cmp\rp,#TI81XXUART2 @ ti81Xx UART offsets different
@@ -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 */
@@ -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)
On Mon, Jul 09, 2012 at 16:09:59, Shilimkar, Santosh wrote:
On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath [off-list ref] wrote:
quoted
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
quoted
From: R Sricharan <redacted>
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 <redacted>
Signed-off-by: Santosh Shilimkar <redacted>
---
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?
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 [off-list ref] wrote:
On Mon, Jul 09, 2012 at 16:09:59, Shilimkar, Santosh wrote:
quoted
On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath [off-list ref] wrote:
quoted
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
quoted
From: R Sricharan <redacted>
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 <redacted>
Signed-off-by: Santosh Shilimkar <redacted>
---
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.
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 [off-list ref] wrote:
quoted
On Mon, Jul 09, 2012 at 16:09:59, Shilimkar, Santosh wrote:
quoted
On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath [off-list ref] wrote:
quoted
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
quoted
From: R Sricharan <redacted>
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 <redacted>
Signed-off-by: Santosh Shilimkar <redacted>
---
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.
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.
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
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 [off-list ref] wrote:
quoted
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
quoted
From: R Sricharan <redacted>
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 [off-list ref] wrote:
On Mon, Jul 09, 2012 at 16:12:15, Shilimkar, Santosh wrote:
quoted
On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath [off-list ref] wrote:
quoted
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
quoted
From: R Sricharan <redacted>
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 [off-list ref] wrote:
quoted
On Mon, Jul 09, 2012 at 16:12:15, Shilimkar, Santosh wrote:
quoted
On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath [off-list ref] wrote:
quoted
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote:
quoted
From: R Sricharan <redacted>
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.
quoted
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
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
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?
...
quoted
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.
quoted
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
On Tue, Jul 10, 2012 at 13:48:52, Tony Lindgren wrote:
quoted
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
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
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.
quoted
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..
quoted
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:
quoted
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?
quoted
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.
quoted
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
From: Roger Quadros <hidden> Date: 2012-11-02 10:03:45
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:
quoted hunk
From: R Sricharan <redacted>
Adding the OMAP5 ES1.0, 2.0 and OMAP5432 cpu revision
detection support.
Signed-off-by: R Sricharan <redacted>
Signed-off-by: Santosh Shilimkar <redacted>
---
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(-)
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