LinuxLists.cc - [PATCH 0/7] msm: Support for Qualcomm MSM8960

[permalink] [raw]

Subject: [PATCH 1/7] msm: io: I/O register definitions for MSM8960

Add the register address definitions for the basic hardware
blocks on the Qualcomm MSM8960 chip.

Signed-off-by: Stepan Moskovchenko <[email protected]>
---
arch/arm/mach-msm/include/mach/io.h | 1 +
arch/arm/mach-msm/include/mach/msm_iomap-8960.h | 55 +++++++++++++++++++++++
arch/arm/mach-msm/include/mach/msm_iomap.h | 2 +
arch/arm/mach-msm/io.c | 14 ++++++
4 files changed, 72 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-msm/include/mach/msm_iomap-8960.h

diff --git a/arch/arm/mach-msm/include/mach/io.h b/arch/arm/mach-msm/include/mach/io.h
index 7386e73..dc1b928 100644
--- a/arch/arm/mach-msm/include/mach/io.h
+++ b/arch/arm/mach-msm/include/mach/io.h
@@ -29,6 +29,7 @@ void __iomem *__msm_ioremap(unsigned long phys_addr, size_t size, unsigned int m
void msm_map_qsd8x50_io(void);
void msm_map_msm7x30_io(void);
void msm_map_msm8x60_io(void);
+void msm_map_msm8960_io(void);

extern unsigned int msm_shared_ram_phys;

diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-8960.h b/arch/arm/mach-msm/include/mach/msm_iomap-8960.h
new file mode 100644
index 0000000..ca6bf90
--- /dev/null
+++ b/arch/arm/mach-msm/include/mach/msm_iomap-8960.h
@@ -0,0 +1,55 @@
+/*
+ * Copyright (C) 2007 Google, Inc.
+ * Copyright (c) 2008-2010, Code Aurora Forum. All rights reserved.
+ * Author: Brian Swetland <[email protected]>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ *
+ * The MSM peripherals are spread all over across 768MB of physical
+ * space, which makes just having a simple IO_ADDRESS macro to slide
+ * them into the right virtual location rough. Instead, we will
+ * provide a master phys->virt mapping for peripherals here.
+ *
+ */
+
+#ifndef __ASM_ARCH_MSM_IOMAP_8960_H
+#define __ASM_ARCH_MSM_IOMAP_8960_H
+
+/* Physical base address and size of peripherals.
+ * Ordered by the virtual base addresses they will be mapped at.
+ *
+ * If you add or remove entries here, you'll want to edit the
+ * msm_io_desc array in arch/arm/mach-msm/io.c to reflect your
+ * changes.
+ *
+ */
+
+
+#define MSM_QGIC_DIST_BASE IOMEM(0xF0000000)
+#define MSM_QGIC_DIST_PHYS 0x02000000
+#define MSM_QGIC_DIST_SIZE SZ_4K
+
+#define MSM_QGIC_CPU_BASE IOMEM(0xF0001000)
+#define MSM_QGIC_CPU_PHYS 0x02002000
+#define MSM_QGIC_CPU_SIZE SZ_4K
+
+#define MSM_TMR_BASE IOMEM(0xF0100000)
+#define MSM_TMR_PHYS 0x0200A000
+#define MSM_TMR_SIZE (SZ_4K)
+
+#define MSM_TMR0_BASE IOMEM(0xF0101000)
+#define MSM_TMR0_PHYS 0x0208A000
+#define MSM_TMR0_SIZE (SZ_4K)
+
+#define MSM_GPT_BASE (MSM_TMR_BASE + 0x4)
+#define MSM_DGT_BASE (MSM_TMR_BASE + 0x24)
+
+#endif
diff --git a/arch/arm/mach-msm/include/mach/msm_iomap.h b/arch/arm/mach-msm/include/mach/msm_iomap.h
index 8e24dd8..4154a0a 100644
--- a/arch/arm/mach-msm/include/mach/msm_iomap.h
+++ b/arch/arm/mach-msm/include/mach/msm_iomap.h
@@ -49,6 +49,8 @@
#include "msm_iomap-8x50.h"
#elif defined(CONFIG_ARCH_MSM8X60)
#include "msm_iomap-8x60.h"
+#elif defined(CONFIG_ARCH_MSM8960)
+#include "msm_iomap-8960.h"
#else
#include "msm_iomap-7x00.h"
#endif
diff --git a/arch/arm/mach-msm/io.c b/arch/arm/mach-msm/io.c
index b826b6b..8254fc4 100644
--- a/arch/arm/mach-msm/io.c
+++ b/arch/arm/mach-msm/io.c
@@ -116,6 +116,20 @@ void __init msm_map_msm8x60_io(void)
}
#endif /* CONFIG_ARCH_MSM8X60 */

+#ifdef CONFIG_ARCH_MSM8960
+static struct map_desc msm8960_io_desc[] __initdata = {
+ MSM_DEVICE(QGIC_DIST),
+ MSM_DEVICE(QGIC_CPU),
+ MSM_DEVICE(TMR),
+ MSM_DEVICE(TMR0),
+};
+
+void __init msm_map_msm8960_io(void)
+{
+ iotable_init(msm8960_io_desc, ARRAY_SIZE(msm8960_io_desc));
+}
+#endif /* CONFIG_ARCH_MSM8960 */
+
#ifdef CONFIG_ARCH_MSM7X30
static struct map_desc msm7x30_io_desc[] __initdata = {
MSM_DEVICE(VIC),
--
1.7.0.2

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2010-12-15 03:49:41

[permalink] [raw]

Subject: [PATCH 7/7] msm: Build support for the MSM8960 target

Add the Kconfig options and Makefile options needed to
build for the MSM8960 target. Only the simulator is
supported at this time.

Signed-off-by: Stepan Moskovchenko <[email protected]>
---
arch/arm/mach-msm/Kconfig | 16 ++++++++++++++++
arch/arm/mach-msm/Makefile | 2 ++
2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 8c57425..ba5c955 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -47,6 +47,16 @@ config ARCH_MSM8X60
select MSM_GPIOMUX
select MSM_SCM if SMP

+config ARCH_MSM8960
+ bool "MSM8960"
+ select ARCH_MSM_SCORPIONMP
+ select MACH_MSM8960_SIM
+ select ARM_GIC
+ select CPU_V7
+ select MSM_V2_TLMM
+ select MSM_GPIOMUX
+ select MSM_SCM if SMP
+
endchoice

config MSM_SOC_REV_A
@@ -124,6 +134,12 @@ config MACH_MSM8X60_FFA
help
Support for the Qualcomm MSM8x60 FFA eval board.

+config MACH_MSM8960_SIM
+ depends on ARCH_MSM8960
+ bool "MSM8960 Simulator"
+ help
+ Support for the Qualcomm MSM8960 simulator.
+
endmenu

config MSM_DEBUG_UART
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index 8cd0b5b..9e5717b 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_ARCH_MSM7X00A) += dma.o irq.o acpuclock-arm11.o
obj-$(CONFIG_ARCH_MSM7X30) += dma.o
obj-$(CONFIG_ARCH_QSD8X50) += dma.o sirc.o
obj-$(CONFIG_ARCH_MSM8X60) += clock-dummy.o iommu.o iommu_dev.o devices-msm8x60-iommu.o
+obj-$(CONFIG_ARCH_MSM8960) += clock-dummy.o iommu.o iommu_dev.o

obj-$(CONFIG_MSM_PROC_COMM) += proc_comm.o clock-pcom.o vreg.o
obj-$(CONFIG_MSM_PROC_COMM) += clock.o
@@ -22,6 +23,7 @@ obj-$(CONFIG_MACH_HALIBUT) += board-halibut.o devices-msm7x00.o
obj-$(CONFIG_ARCH_MSM7X30) += board-msm7x30.o devices-msm7x30.o
obj-$(CONFIG_ARCH_QSD8X50) += board-qsd8x50.o devices-qsd8x50.o
obj-$(CONFIG_ARCH_MSM8X60) += board-msm8x60.o
+obj-$(CONFIG_ARCH_MSM8960) += board-msm8960.o

obj-$(CONFIG_ARCH_MSM7X30) += gpiomux-7x30.o gpiomux-v1.o gpiomux.o
obj-$(CONFIG_ARCH_QSD8X50) += gpiomux-8x50.o gpiomux-v1.o gpiomux.o
--
1.7.0.2

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2010-12-15 03:49:42

[permalink] [raw]

Subject: [PATCH 6/7] msm: Makefile cleanup

Clean up some of the conditionals in the Makefile in
preparation for adding build support for MSM8960.

Signed-off-by: Stepan Moskovchenko <[email protected]>
---
arch/arm/mach-msm/Makefile | 18 ++++++------------
1 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index 1945f9c..8cd0b5b 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -1,21 +1,15 @@
obj-y += io.o idle.o timer.o
-ifndef CONFIG_ARCH_MSM8X60
-obj-y += acpuclock-arm11.o
-obj-y += dma.o
-endif

-ifdef CONFIG_MSM_VIC
-obj-y += irq-vic.o
-else
-ifndef CONFIG_ARCH_MSM8X60
-obj-y += irq.o
-endif
-endif
+obj-$(CONFIG_MSM_VIC) += irq-vic.o

+obj-$(CONFIG_ARCH_MSM7X00A) += dma.o irq.o acpuclock-arm11.o
+obj-$(CONFIG_ARCH_MSM7X30) += dma.o
+obj-$(CONFIG_ARCH_QSD8X50) += dma.o sirc.o
obj-$(CONFIG_ARCH_MSM8X60) += clock-dummy.o iommu.o iommu_dev.o devices-msm8x60-iommu.o
+
obj-$(CONFIG_MSM_PROC_COMM) += proc_comm.o clock-pcom.o vreg.o
obj-$(CONFIG_MSM_PROC_COMM) += clock.o
-obj-$(CONFIG_ARCH_QSD8X50) += sirc.o
+
obj-$(CONFIG_MSM_SMD) += smd.o smd_debug.o
obj-$(CONFIG_MSM_SMD) += last_radio_log.o
obj-$(CONFIG_MSM_SCM) += scm.o scm-boot.o
--
1.7.0.2

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2010-12-15 03:50:00

[permalink] [raw]

Subject: [PATCH 5/7] msm: timer: Timer support for MSM8960

Modify the macros in the MSM timer driver to support the
MSM8960 chip.

Signed-off-by: Stepan Moskovchenko <[email protected]>
---
arch/arm/mach-msm/timer.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 1154292..c48a449 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -63,7 +63,8 @@ enum timer_location {
#if defined(CONFIG_ARCH_QSD8X50)
#define DGT_HZ (19200000 / 4) /* 19.2 MHz / 4 by default */
#define MSM_DGT_SHIFT (0)
-#elif defined(CONFIG_ARCH_MSM7X30) || defined(CONFIG_ARCH_MSM8X60)
+#elif defined(CONFIG_ARCH_MSM7X30) || defined(CONFIG_ARCH_MSM8X60) || \
+ defined(CONFIG_ARCH_MSM8960)
#define DGT_HZ (24576000 / 4) /* 24.576 MHz (LPXO) / 4 by default */
#define MSM_DGT_SHIFT (0)
#else
--
1.7.0.2

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2010-12-15 03:50:28

[permalink] [raw]

Subject: [PATCH 3/7] msm: irqs-8960: Interrupt map for MSM8960

Add the interrupt map for the Qualcomm MSM8960 chip. This
chip has an interrupt map that is different from previous
targets.

Signed-off-by: Stepan Moskovchenko <[email protected]>
---
arch/arm/mach-msm/include/mach/irqs-8960.h | 293 ++++++++++++++++++++++++++++
arch/arm/mach-msm/include/mach/irqs.h | 2 +
2 files changed, 295 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-msm/include/mach/irqs-8960.h

diff --git a/arch/arm/mach-msm/include/mach/irqs-8960.h b/arch/arm/mach-msm/include/mach/irqs-8960.h
new file mode 100644
index 0000000..f4d8593
--- /dev/null
+++ b/arch/arm/mach-msm/include/mach/irqs-8960.h
@@ -0,0 +1,293 @@
+/* Copyright (c) 2010 Code Aurora Forum. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Code Aurora nor
+ * the names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior written
+ * permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NON-INFRINGEMENT ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+
+#ifndef __ASM_ARCH_MSM_IRQS_8960_H
+#define __ASM_ARCH_MSM_IRQS_8960_H
+
+/* MSM ACPU Interrupt Numbers */
+
+/* 0-15: STI/SGI (software triggered/generated interrupts)
+ 16-31: PPI (private peripheral interrupts)
+ 32+: SPI (shared peripheral interrupts) */
+
+#define GIC_PPI_START 16
+#define GIC_SPI_START 32
+
+#define INT_VGIC (GIC_PPI_START + 0)
+#define INT_DEBUG_TIMER_EXP (GIC_PPI_START + 1)
+#define INT_GP_TIMER_EXP (GIC_PPI_START + 2)
+#define INT_GP_TIMER2_EXP (GIC_PPI_START + 3)
+#define WDT0_ACCSCSSNBARK_INT (GIC_PPI_START + 4)
+#define WDT1_ACCSCSSNBARK_INT (GIC_PPI_START + 5)
+#define AVS_SVICINT (GIC_PPI_START + 6)
+#define AVS_SVICINTSWDONE (GIC_PPI_START + 7)
+#define CPU_DBGCPUXCOMMRXFULL (GIC_PPI_START + 8)
+#define CPU_DBGCPUXCOMMTXEMPTY (GIC_PPI_START + 9)
+#define CPU_SICCPUXPERFMONIRPTREQ (GIC_PPI_START + 10)
+#define SC_AVSCPUXDOWN (GIC_PPI_START + 11)
+#define SC_AVSCPUXUP (GIC_PPI_START + 12)
+#define SC_SICCPUXACGIRPTREQ (GIC_PPI_START + 13)
+#define SC_SICCPUXEXTFAULTIRPTREQ (GIC_PPI_START + 14)
+/* PPI 15 is unused */
+
+#define SC_SICMPUIRPTREQ (GIC_SPI_START + 0)
+#define SC_SICL2IRPTREQ (GIC_SPI_START + 1)
+#define SC_SICL2PERFMONIRPTREQ (GIC_SPI_START + 2)
+#define SC_SICAGCIRPTREQ (GIC_SPI_START + 3)
+#define TLMM_APCC_DIR_CONN_IRQ_0 (GIC_SPI_START + 4)
+#define TLMM_APCC_DIR_CONN_IRQ_1 (GIC_SPI_START + 5)
+#define TLMM_APCC_DIR_CONN_IRQ_2 (GIC_SPI_START + 6)
+#define TLMM_APCC_DIR_CONN_IRQ_3 (GIC_SPI_START + 7)
+#define TLMM_APCC_DIR_CONN_IRQ_4 (GIC_SPI_START + 8)
+#define TLMM_APCC_DIR_CONN_IRQ_5 (GIC_SPI_START + 9)
+#define TLMM_APCC_DIR_CONN_IRQ_6 (GIC_SPI_START + 10)
+#define TLMM_APCC_DIR_CONN_IRQ_7 (GIC_SPI_START + 11)
+#define TLMM_APCC_DIR_CONN_IRQ_8 (GIC_SPI_START + 12)
+#define TLMM_APCC_DIR_CONN_IRQ_9 (GIC_SPI_START + 13)
+#define PM8921_SEC_IRQ_103 (GIC_SPI_START + 14)
+#define PM8018_SEC_IRQ_106 (GIC_SPI_START + 15)
+#define TLMM_APCC_SUMMARY_IRQ (GIC_SPI_START + 16)
+#define SPDM_RT_1_IRQ (GIC_SPI_START + 17)
+#define SPDM_DIAG_IRQ (GIC_SPI_START + 18)
+#define RPM_APCC_CPU0_GP_HIGH_IRQ (GIC_SPI_START + 19)
+#define RPM_APCC_CPU0_GP_MEDIUM_IRQ (GIC_SPI_START + 20)
+#define RPM_APCC_CPU0_GP_LOW_IRQ (GIC_SPI_START + 21)
+#define RPM_APCC_CPU0_WAKE_UP_IRQ (GIC_SPI_START + 22)
+#define RPM_APCC_CPU1_GP_HIGH_IRQ (GIC_SPI_START + 23)
+#define RPM_APCC_CPU1_GP_MEDIUM_IRQ (GIC_SPI_START + 24)
+#define RPM_APCC_CPU1_GP_LOW_IRQ (GIC_SPI_START + 25)
+#define RPM_APCC_CPU1_WAKE_UP_IRQ (GIC_SPI_START + 26)
+#define SSBI2_2_SC_CPU0_SECURE_IRQ (GIC_SPI_START + 27)
+#define SSBI2_2_SC_CPU0_NON_SECURE_IRQ (GIC_SPI_START + 28)
+#define SSBI2_1_SC_CPU0_SECURE_IRQ (GIC_SPI_START + 29)
+#define SSBI2_1_SC_CPU0_NON_SECURE_IRQ (GIC_SPI_START + 30)
+#define MSMC_SC_SEC_CE_IRQ (GIC_SPI_START + 31)
+#define MSMC_SC_PRI_CE_IRQ (GIC_SPI_START + 32)
+#define SLIMBUS0_CORE_EE1_IRQ (GIC_SPI_START + 33)
+#define SLIMBUS0_BAM_EE1_IRQ (GIC_SPI_START + 34)
+#define Q6FW_WDOG_EXPIRED_IRQ (GIC_SPI_START + 35)
+#define Q6SW_WDOG_EXPIRED_IRQ (GIC_SPI_START + 36)
+#define MSS_TO_APPS_IRQ_0 (GIC_SPI_START + 37)
+#define MSS_TO_APPS_IRQ_1 (GIC_SPI_START + 38)
+#define MSS_TO_APPS_IRQ_2 (GIC_SPI_START + 39)
+#define MSS_TO_APPS_IRQ_3 (GIC_SPI_START + 40)
+#define MSS_TO_APPS_IRQ_4 (GIC_SPI_START + 41)
+#define MSS_TO_APPS_IRQ_5 (GIC_SPI_START + 42)
+#define MSS_TO_APPS_IRQ_6 (GIC_SPI_START + 43)
+#define MSS_TO_APPS_IRQ_7 (GIC_SPI_START + 44)
+#define MSS_TO_APPS_IRQ_8 (GIC_SPI_START + 45)
+#define MSS_TO_APPS_IRQ_9 (GIC_SPI_START + 46)
+#define VPE_IRQ (GIC_SPI_START + 47)
+#define VFE_IRQ (GIC_SPI_START + 48)
+#define VCODEC_IRQ (GIC_SPI_START + 49)
+#define TV_ENC_IRQ (GIC_SPI_START + 50)
+#define SMMU_VPE_CB_SC_SECURE_IRQ (GIC_SPI_START + 51)
+#define SMMU_VPE_CB_SC_NON_SECURE_IRQ (GIC_SPI_START + 52)
+#define SMMU_VFE_CB_SC_SECURE_IRQ (GIC_SPI_START + 53)
+#define SMMU_VFE_CB_SC_NON_SECURE_IRQ (GIC_SPI_START + 54)
+#define SMMU_VCODEC_B_CB_SC_SECURE_IRQ (GIC_SPI_START + 55)
+#define SMMU_VCODEC_B_CB_SC_NON_SECURE_IRQ (GIC_SPI_START + 56)
+#define SMMU_VCODEC_A_CB_SC_SECURE_IRQ (GIC_SPI_START + 57)
+#define SMMU_VCODEC_A_CB_SC_NON_SECURE_IRQ (GIC_SPI_START + 58)
+#define SMMU_ROT_CB_SC_SECURE_IRQ (GIC_SPI_START + 59)
+#define SMMU_ROT_CB_SC_NON_SECURE_IRQ (GIC_SPI_START + 60)
+#define SMMU_MDP1_CB_SC_SECURE_IRQ (GIC_SPI_START + 61)
+#define SMMU_MDP1_CB_SC_NON_SECURE_IRQ (GIC_SPI_START + 62)
+#define SMMU_MDP0_CB_SC_SECURE_IRQ (GIC_SPI_START + 63)
+#define SMMU_MDP0_CB_SC_NON_SECURE_IRQ (GIC_SPI_START + 64)
+#define SMMU_JPEGD_CB_SC_SECURE_IRQ (GIC_SPI_START + 65)
+#define SMMU_JPEGD_CB_SC_NON_SECURE_IRQ (GIC_SPI_START + 66)
+#define SMMU_IJPEG_CB_SC_SECURE_IRQ (GIC_SPI_START + 67)
+#define SMMU_IJPEG_CB_SC_NON_SECURE_IRQ (GIC_SPI_START + 68)
+#define SMMU_GFX3D_CB_SC_SECURE_IRQ (GIC_SPI_START + 69)
+#define SMMU_GFX3D_CB_SC_NON_SECURE_IRQ (GIC_SPI_START + 70)
+#define SMMU_GFX2D0_CB_SC_SECURE_IRQ (GIC_SPI_START + 71)
+#define SMMU_GFX2D0_CB_SC_NON_SECURE_IRQ (GIC_SPI_START + 72)
+#define ROT_IRQ (GIC_SPI_START + 73)
+#define MMSS_FABRIC_IRQ (GIC_SPI_START + 74)
+#define MDP_IRQ (GIC_SPI_START + 75)
+#define JPEGD_IRQ (GIC_SPI_START + 76)
+#define JPEG_IRQ (GIC_SPI_START + 77)
+#define MMSS_IMEM_IRQ (GIC_SPI_START + 78)
+#define HDMI_IRQ (GIC_SPI_START + 79)
+#define GFX3D_IRQ (GIC_SPI_START + 80)
+#define GFX2D0_IRQ (GIC_SPI_START + 81)
+#define DSI1_IRQ (GIC_SPI_START + 82)
+#define CSI_1_IRQ (GIC_SPI_START + 83)
+#define CSI_0_IRQ (GIC_SPI_START + 84)
+#define LPASS_SCSS_AUDIO_IF_OUT0_IRQ (GIC_SPI_START + 85)
+#define LPASS_SCSS_MIDI_IRQ (GIC_SPI_START + 86)
+#define LPASS_Q6SS_WDOG_EXPIRED (GIC_SPI_START + 87)
+#define LPASS_SCSS_GP_LOW_IRQ (GIC_SPI_START + 88)
+#define LPASS_SCSS_GP_MEDIUM_IRQ (GIC_SPI_START + 89)
+#define LPASS_SCSS_GP_HIGH_IRQ (GIC_SPI_START + 90)
+#define TOP_IMEM_IRQ (GIC_SPI_START + 91)
+#define FABRIC_SYS_IRQ (GIC_SPI_START + 92)
+#define FABRIC_APPS_IRQ (GIC_SPI_START + 93)
+#define USB1_HS_BAM_IRQ (GIC_SPI_START + 94)
+#define SDC4_BAM_IRQ (GIC_SPI_START + 95)
+#define SDC3_BAM_IRQ (GIC_SPI_START + 96)
+#define SDC2_BAM_IRQ (GIC_SPI_START + 97)
+#define SDC1_BAM_IRQ (GIC_SPI_START + 98)
+#define FABRIC_SPS_IRQ (GIC_SPI_START + 99)
+#define USB1_HS_IRQ (GIC_SPI_START + 100)
+#define SDC4_IRQ_0 (GIC_SPI_START + 101)
+#define SDC3_IRQ_0 (GIC_SPI_START + 102)
+#define SDC2_IRQ_0 (GIC_SPI_START + 103)
+#define SDC1_IRQ_0 (GIC_SPI_START + 104)
+#define SPS_BAM_DMA_IRQ (GIC_SPI_START + 105)
+#define SPS_SEC_VIOL_IRQ (GIC_SPI_START + 106)
+#define SPS_MTI_0 (GIC_SPI_START + 107)
+#define SPS_MTI_1 (GIC_SPI_START + 108)
+#define SPS_MTI_2 (GIC_SPI_START + 109)
+#define SPS_MTI_3 (GIC_SPI_START + 110)
+#define SPS_MTI_4 (GIC_SPI_START + 111)
+#define SPS_MTI_5 (GIC_SPI_START + 112)
+#define SPS_MTI_6 (GIC_SPI_START + 113)
+#define SPS_MTI_7 (GIC_SPI_START + 114)
+#define SPS_MTI_8 (GIC_SPI_START + 115)
+#define SPS_MTI_9 (GIC_SPI_START + 116)
+#define SPS_MTI_10 (GIC_SPI_START + 117)
+#define SPS_MTI_11 (GIC_SPI_START + 118)
+#define SPS_MTI_12 (GIC_SPI_START + 119)
+#define SPS_MTI_13 (GIC_SPI_START + 120)
+#define SPS_MTI_14 (GIC_SPI_START + 121)
+#define SPS_MTI_15 (GIC_SPI_START + 122)
+#define SPS_MTI_16 (GIC_SPI_START + 123)
+#define SPS_MTI_17 (GIC_SPI_START + 124)
+#define SPS_MTI_18 (GIC_SPI_START + 125)
+#define SPS_MTI_19 (GIC_SPI_START + 126)
+#define SPS_MTI_20 (GIC_SPI_START + 127)
+#define SPS_MTI_21 (GIC_SPI_START + 128)
+#define SPS_MTI_22 (GIC_SPI_START + 129)
+#define SPS_MTI_23 (GIC_SPI_START + 130)
+#define SPS_MTI_24 (GIC_SPI_START + 131)
+#define SPS_MTI_25 (GIC_SPI_START + 132)
+#define SPS_MTI_26 (GIC_SPI_START + 133)
+#define SPS_MTI_27 (GIC_SPI_START + 134)
+#define SPS_MTI_28 (GIC_SPI_START + 135)
+#define SPS_MTI_29 (GIC_SPI_START + 136)
+#define SPS_MTI_30 (GIC_SPI_START + 137)
+#define SPS_MTI_31 (GIC_SPI_START + 138)
+#define CSIPHY_2LN_IRQ (GIC_SPI_START + 139)
+#define CSIPHY_4LN_IRQ (GIC_SPI_START + 140)
+#define USB2_IRQ (GIC_SPI_START + 141)
+#define USB1_IRQ (GIC_SPI_START + 142)
+#define TSSC_SSBI_IRQ (GIC_SPI_START + 143)
+#define TSSC_SAMPLE_IRQ (GIC_SPI_START + 144)
+#define TSSC_PENUP_IRQ (GIC_SPI_START + 145)
+#define GSBI1_UARTDM_IRQ (GIC_SPI_START + 193)
+#define GSBI1_QUP_IRQ (GIC_SPI_START + 194)
+#define GSBI2_UARTDM_IRQ (GIC_SPI_START + 148)
+#define GSBI2_QUP_IRQ (GIC_SPI_START + 149)
+#define GSBI3_UARTDM_IRQ (GIC_SPI_START + 150)
+#define GSBI3_QUP_IRQ (GIC_SPI_START + 151)
+#define GSBI4_UARTDM_IRQ (GIC_SPI_START + 152)
+#define GSBI4_QUP_IRQ (GIC_SPI_START + 153)
+#define GSBI5_UARTDM_IRQ (GIC_SPI_START + 154)
+#define GSBI5_QUP_IRQ (GIC_SPI_START + 155)
+#define GSBI6_UARTDM_IRQ (GIC_SPI_START + 156)
+#define GSBI6_QUP_IRQ (GIC_SPI_START + 157)
+#define GSBI7_UARTDM_IRQ (GIC_SPI_START + 158)
+#define GSBI7_QUP_IRQ (GIC_SPI_START + 159)
+#define GSBI8_UARTDM_IRQ (GIC_SPI_START + 160)
+#define GSBI8_QUP_IRQ (GIC_SPI_START + 161)
+#define TSIF_TSPP_IRQ (GIC_SPI_START + 162)
+#define TSIF_BAM_IRQ (GIC_SPI_START + 163)
+#define TSIF2_IRQ (GIC_SPI_START + 164)
+#define TSIF1_IRQ (GIC_SPI_START + 165)
+#define DSI2_IRQ (GIC_SPI_START + 166)
+#define ISPIF_IRQ (GIC_SPI_START + 167)
+#define MSMC_SC_SEC_TMR_IRQ (GIC_SPI_START + 168)
+#define MSMC_SC_SEC_WDOG_BARK_IRQ (GIC_SPI_START + 169)
+#define INT_ADM0_SCSS_0_IRQ (GIC_SPI_START + 170)
+#define INT_ADM0_SCSS_1_IRQ (GIC_SPI_START + 171)
+#define INT_ADM0_SCSS_2_IRQ (GIC_SPI_START + 172)
+#define INT_ADM0_SCSS_3_IRQ (GIC_SPI_START + 173)
+#define CC_SCSS_WDT1CPU1BITEEXPIRED (GIC_SPI_START + 174)
+#define CC_SCSS_WDT1CPU0BITEEXPIRED (GIC_SPI_START + 175)
+#define CC_SCSS_WDT0CPU1BITEEXPIRED (GIC_SPI_START + 176)
+#define CC_SCSS_WDT0CPU0BITEEXPIRED (GIC_SPI_START + 177)
+#define TSENS_UPPER_LOWER_INT (GIC_SPI_START + 178)
+#define SSBI2_2_SC_CPU1_SECURE_INT (GIC_SPI_START + 179)
+#define SSBI2_2_SC_CPU1_NON_SECURE_INT (GIC_SPI_START + 180)
+#define SSBI2_1_SC_CPU1_SECURE_INT (GIC_SPI_START + 181)
+#define SSBI2_1_SC_CPU1_NON_SECURE_INT (GIC_SPI_START + 182)
+#define XPU_SUMMARY_IRQ (GIC_SPI_START + 183)
+#define BUS_EXCEPTION_SUMMARY_IRQ (GIC_SPI_START + 184)
+#define HSDDRX_EBI1CH0_IRQ (GIC_SPI_START + 185)
+#define HSDDRX_EBI1CH1_IRQ (GIC_SPI_START + 186)
+#define SDC5_BAM_IRQ (GIC_SPI_START + 187)
+#define SDC5_IRQ_0 (GIC_SPI_START + 188)
+#define GSBI9_UARTDM_IRQ (GIC_SPI_START + 189)
+#define GSBI9_QUP_IRQ (GIC_SPI_START + 190)
+#define GSBI10_UARTDM_IRQ (GIC_SPI_START + 191)
+#define GSBI10_QUP_IRQ (GIC_SPI_START + 192)
+#define GSBI11_UARTDM_IRQ (GIC_SPI_START + 193)
+#define GSBI11_QUP_IRQ (GIC_SPI_START + 194)
+#define GSBI12_UARTDM_IRQ (GIC_SPI_START + 195)
+#define GSBI12_QUP_IRQ (GIC_SPI_START + 196)
+#define RIVA_APSS_LTECOEX_IRQ (GIC_SPI_START + 197)
+#define RIVA_APSS_SPARE_IRQ (GIC_SPI_START + 198)
+#define RIVA_APSS_WDOG_BITE_RESET_RDY_IRQ (GIC_SPI_START + 199)
+#define RIVA_ASS_RESET_DONE_IRQ (GIC_SPI_START + 200)
+#define RIVA_APSS_ASIC_IRQ (GIC_SPI_START + 201)
+#define RIVA_APPS_WLAN_RX_DATA_AVAIL_IRQ (GIC_SPI_START + 202)
+#define RIVA_APPS_WLAN_DATA_XFER_DONE_IRQ (GIC_SPI_START + 203)
+#define RIVA_APPS_WLAM_SMSM_IRQ (GIC_SPI_START + 204)
+#define RIVA_APPS_LOG_CTRL_IRQ (GIC_SPI_START + 205)
+#define RIVA_APPS_FM_CTRL_IRQ (GIC_SPI_START + 206)
+#define RIVA_APPS_HCI_IRQ (GIC_SPI_START + 207)
+#define RIVA_APPS_WLAN_CTRL_IRQ (GIC_SPI_START + 208)
+#define A2_BAM_IRQ (GIC_SPI_START + 209)
+#define SMMU_GFX2D1_CB_SC_SECURE_IRQ (GIC_SPI_START + 210)
+#define SMMU_GFX2D1_CB_SC_NON_SECURE_IRQ (GIC_SPI_START + 211)
+#define GFX2D1_IRQ (GIC_SPI_START + 212)
+#define PPSS_WDOG_TIMER_IRQ (GIC_SPI_START + 213)
+#define SPS_SLIMBUS_CORE_EE0_IRQ (GIC_SPI_START + 214)
+#define SPS_SLIMBUS_BAM_EE0_IRQ (GIC_SPI_START + 215)
+#define QDSS_ETB_IRQ (GIC_SPI_START + 216)
+#define QDSS_CTI2KPSS_CPU1_IRQ (GIC_SPI_START + 217)
+#define QDSS_CTI2KPSS_CPU0_IRQ (GIC_SPI_START + 218)
+#define TLMM_APCC_DIR_CONN_IRQ_16 (GIC_SPI_START + 219)
+#define TLMM_APCC_DIR_CONN_IRQ_17 (GIC_SPI_START + 220)
+#define TLMM_APCC_DIR_CONN_IRQ_18 (GIC_SPI_START + 221)
+#define TLMM_APCC_DIR_CONN_IRQ_19 (GIC_SPI_START + 222)
+#define TLMM_APCC_DIR_CONN_IRQ_20 (GIC_SPI_START + 223)
+#define TLMM_APCC_DIR_CONN_IRQ_21 (GIC_SPI_START + 224)
+#define PM8921_SEC_IRQ_104 (GIC_SPI_START + 225)
+#define PM8018_SEC_IRQ_107 (GIC_SPI_START + 226)
+
+/* For now, use the maximum number of interrupts until a pending GIC issue
+ * is sorted out */
+#define NR_MSM_IRQS 1020
+#define NR_BOARD_IRQS 0
+#define NR_GPIO_IRQS 0
+
+#endif
+
diff --git a/arch/arm/mach-msm/include/mach/irqs.h b/arch/arm/mach-msm/include/mach/irqs.h
index 8679a45..e2cb037 100644
--- a/arch/arm/mach-msm/include/mach/irqs.h
+++ b/arch/arm/mach-msm/include/mach/irqs.h
@@ -26,6 +26,8 @@
#include "sirc.h"
#elif defined(CONFIG_ARCH_MSM8X60)
#include "irqs-8x60.h"
+#elif defined(CONFIG_ARCH_MSM8960)
+#include "irqs-8960.h"
#elif defined(CONFIG_ARCH_MSM_ARM11)
#include "irqs-7x00.h"
#else
--
1.7.0.2

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2010-12-15 03:50:26

[permalink] [raw]

Subject: [PATCH 4/7] msm: Board file for MSM8960 simulator

Add a basic board file needed to boot the kernel on the
MSM8960 simulator.

Signed-off-by: Stepan Moskovchenko <[email protected]>
---
arch/arm/mach-msm/board-msm8960.c | 71 +++++++++++++++++++++++++++++++++++++
1 files changed, 71 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-msm/board-msm8960.c

diff --git a/arch/arm/mach-msm/board-msm8960.c b/arch/arm/mach-msm/board-msm8960.c
new file mode 100644
index 0000000..7a1b80a
--- /dev/null
+++ b/arch/arm/mach-msm/board-msm8960.c
@@ -0,0 +1,71 @@
+/* Copyright (c) 2010, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <asm/hardware/gic.h>
+
+#include <mach/board.h>
+#include <mach/msm_iomap.h>
+
+void __iomem *gic_cpu_base_addr;
+
+static void __init msm8960_map_io(void)
+{
+ msm_map_msm8960_io();
+}
+
+static void __init msm8960_init_irq(void)
+{
+ unsigned int i;
+
+ gic_dist_init(0, MSM_QGIC_DIST_BASE, GIC_PPI_START);
+ gic_cpu_base_addr = (void *)MSM_QGIC_CPU_BASE;
+ gic_cpu_init(0, MSM_QGIC_CPU_BASE);
+
+ /* Edge trigger PPIs except AVS_SVICINT and AVS_SVICINTSWDONE */
+ writel(0xFFFFD7FF, MSM_QGIC_DIST_BASE + GIC_DIST_CONFIG + 4);
+
+ /* FIXME: Not installing AVS_SVICINT and AVS_SVICINTSWDONE yet
+ * as they are configured as level, which does not play nice with
+ * handle_percpu_irq.
+ */
+ for (i = GIC_PPI_START; i < GIC_SPI_START; i++) {
+ if (i != AVS_SVICINT && i != AVS_SVICINTSWDONE)
+ set_irq_handler(i, handle_percpu_irq);
+ }
+}
+
+static void __init msm8960_sim_init(void)
+{
+}
+
+MACHINE_START(MSM8960_SIM, "QCT MSM8960 SIMULATOR")
+#ifdef CONFIG_MSM_DEBUG_UART
+ .phys_io = MSM_DEBUG_UART_PHYS,
+ .io_pg_offst = ((MSM_DEBUG_UART_BASE) >> 18) & 0xfffc,
+#endif
+ .map_io = msm8960_map_io,
+ .init_irq = msm8960_init_irq,
+ .init_machine = msm8960_sim_init,
+ .timer = &msm_timer,
+MACHINE_END
--
1.7.0.2

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2010-12-15 03:50:55

[permalink] [raw]

Subject: [PATCH 2/7] msm: Physical offset for MSM8960

Add the physical memory offset value for the Qualcomm
MSM8960 chip.

Signed-off-by: Stepan Moskovchenko <[email protected]>
---
arch/arm/mach-msm/include/mach/memory.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-msm/include/mach/memory.h b/arch/arm/mach-msm/include/mach/memory.h
index 070e17d..014bbd3 100644
--- a/arch/arm/mach-msm/include/mach/memory.h
+++ b/arch/arm/mach-msm/include/mach/memory.h
@@ -25,6 +25,8 @@
#define PHYS_OFFSET UL(0x00200000)
#elif defined(CONFIG_ARCH_MSM8X60)
#define PHYS_OFFSET UL(0x40200000)
+#elif defined(CONFIG_ARCH_MSM8960)
+#define PHYS_OFFSET UL(0x40200000)
#else
#define PHYS_OFFSET UL(0x10000000)
#endif
--
1.7.0.2

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2010-12-15 13:18:51

by Sergei Shtylyov

[permalink] [raw]

Subject: Re: [PATCH 2/7] msm: Physical offset for MSM8960

Hello.

On 15-12-2010 6:49, Stepan Moskovchenko wrote:

> Add the physical memory offset value for the Qualcomm
> MSM8960 chip.

> Signed-off-by: Stepan Moskovchenko<[email protected]>
[...]

> diff --git a/arch/arm/mach-msm/include/mach/memory.h b/arch/arm/mach-msm/include/mach/memory.h
> index 070e17d..014bbd3 100644
> --- a/arch/arm/mach-msm/include/mach/memory.h
> +++ b/arch/arm/mach-msm/include/mach/memory.h
> @@ -25,6 +25,8 @@
> #define PHYS_OFFSET UL(0x00200000)
> #elif defined(CONFIG_ARCH_MSM8X60)
> #define PHYS_OFFSET UL(0x40200000)
> +#elif defined(CONFIG_ARCH_MSM8960)
> +#define PHYS_OFFSET UL(0x40200000)

Why not:

-#elif defined(CONFIG_ARCH_MSM8X60)
+#elif defined(CONFIG_ARCH_MSM8X60) || defined(CONFIG_ARCH_MSM8960)

WBR, Sergei

2010-12-15 13:55:12

[permalink] [raw]

Subject: Re: [PATCH 2/7] msm: Physical offset for MSM8960

On Wed, Dec 15, 2010 at 04:17:48PM +0300, Sergei Shtylyov wrote:

> On 15-12-2010 6:49, Stepan Moskovchenko wrote:
>
> > Add the physical memory offset value for the Qualcomm
> > MSM8960 chip.
>
> > Signed-off-by: Stepan Moskovchenko<[email protected]>
> [...]
>
> > diff --git a/arch/arm/mach-msm/include/mach/memory.h b/arch/arm/mach-msm/include/mach/memory.h
> > index 070e17d..014bbd3 100644
> > --- a/arch/arm/mach-msm/include/mach/memory.h
> > +++ b/arch/arm/mach-msm/include/mach/memory.h
> > @@ -25,6 +25,8 @@
> > #define PHYS_OFFSET UL(0x00200000)
> > #elif defined(CONFIG_ARCH_MSM8X60)
> > #define PHYS_OFFSET UL(0x40200000)
> > +#elif defined(CONFIG_ARCH_MSM8960)
> > +#define PHYS_OFFSET UL(0x40200000)
>
> Why not:
>
> -#elif defined(CONFIG_ARCH_MSM8X60)
> +#elif defined(CONFIG_ARCH_MSM8X60) || defined(CONFIG_ARCH_MSM8960)

I guess it's a matter of style, and what one is trying to emphasize.
Having each one listed makes it easier to change them individually.
The file is just a listing of the addresses of each chip, so I don't
see much reason to try and compact it.

Thanks,
David

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2010-12-15 14:41:47

by Daniel Walker

[permalink] [raw]

Subject: Re: [PATCH 2/7] msm: Physical offset for MSM8960

On Wed, 2010-12-15 at 05:55 -0800, David Brown wrote:
> On Wed, Dec 15, 2010 at 04:17:48PM +0300, Sergei Shtylyov wrote:
>
> > On 15-12-2010 6:49, Stepan Moskovchenko wrote:
> >
> > > Add the physical memory offset value for the Qualcomm
> > > MSM8960 chip.
> >
> > > Signed-off-by: Stepan Moskovchenko<[email protected]>
> > [...]
> >
> > > diff --git a/arch/arm/mach-msm/include/mach/memory.h b/arch/arm/mach-msm/include/mach/memory.h
> > > index 070e17d..014bbd3 100644
> > > --- a/arch/arm/mach-msm/include/mach/memory.h
> > > +++ b/arch/arm/mach-msm/include/mach/memory.h
> > > @@ -25,6 +25,8 @@
> > > #define PHYS_OFFSET UL(0x00200000)
> > > #elif defined(CONFIG_ARCH_MSM8X60)
> > > #define PHYS_OFFSET UL(0x40200000)
> > > +#elif defined(CONFIG_ARCH_MSM8960)
> > > +#define PHYS_OFFSET UL(0x40200000)
> >
> > Why not:
> >
> > -#elif defined(CONFIG_ARCH_MSM8X60)
> > +#elif defined(CONFIG_ARCH_MSM8X60) || defined(CONFIG_ARCH_MSM8960)
>
> I guess it's a matter of style, and what one is trying to emphasize.
> Having each one listed makes it easier to change them individually.
> The file is just a listing of the addresses of each chip, so I don't
> see much reason to try and compact it.

It just shows a deeper issue, that the namespace needs work. There's too
much duplication here vs. 8x60 .. If you look over this whole patchset
it looks very much like 8x60 was just copied over.

Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.

2010-12-15 15:31:31

[permalink] [raw]

Subject: Re: [PATCH 1/7] msm: io: I/O register definitions for MSM8960

On Wednesday 15 December 2010, Stepan Moskovchenko wrote:
> diff --git a/arch/arm/mach-msm/include/mach/msm_iomap.h b/arch/arm/mach-msm/include/mach/msm_iomap.h
> index 8e24dd8..4154a0a 100644
> --- a/arch/arm/mach-msm/include/mach/msm_iomap.h
> +++ b/arch/arm/mach-msm/include/mach/msm_iomap.h
> @@ -49,6 +49,8 @@
> #include "msm_iomap-8x50.h"
> #elif defined(CONFIG_ARCH_MSM8X60)
> #include "msm_iomap-8x60.h"
> +#elif defined(CONFIG_ARCH_MSM8960)
> +#include "msm_iomap-8960.h"
> #else
> #include "msm_iomap-7x00.h"
> #endif

As a general comment, try to make the config options like this nonexclusive,
so you can build kernels to run on multiple CPUs.

In this particular case, it's rather confusing, because one would assume
that MSM8960 is a subset of MSM8X60!

Arnd

2010-12-15 15:34:57

[permalink] [raw]

Subject: Re: [PATCH 7/7] msm: Build support for the MSM8960 target

On Wednesday 15 December 2010, Stepan Moskovchenko wrote:
> Add the Kconfig options and Makefile options needed to
> build for the MSM8960 target. Only the simulator is
> supported at this time.
>
> Signed-off-by: Stepan Moskovchenko <[email protected]>

There is no need to split the Makefile/Kconfig changes
from the actual files implementing the functionality.
It's better to keep these together, since neither of the
patches does anything meaningful by itself.

Splitting out the cleanup as you did is good though, it
helps with review and with possible bisection or rebase
of the patches.

Arnd

2010-12-15 15:35:43

[permalink] [raw]

Subject: Re: [PATCH 1/7] msm: io: I/O register definitions for MSM8960

On Wed, Dec 15, 2010 at 04:31:11PM +0100, Arnd Bergmann wrote:
> On Wednesday 15 December 2010, Stepan Moskovchenko wrote:

> In this particular case, it's rather confusing, because one would assume
> that MSM8960 is a subset of MSM8X60!

Unfortunately, this is not the case, and I'm not sure what better name
to use for MSM8X60. The MSM8X60 name covers MSM8260 and MSM8660, but
MSM8960 is quite a bit different. Any ideas for better names?

David

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2010-12-15 15:36:25

[permalink] [raw]

Subject: Re: [PATCH 4/7] msm: Board file for MSM8960 simulator

On Wednesday 15 December 2010, Stepan Moskovchenko wrote:
> +#ifdef CONFIG_MSM_DEBUG_UART
> + .phys_io = MSM_DEBUG_UART_PHYS,
> + .io_pg_offst = ((MSM_DEBUG_UART_BASE) >> 18) & 0xfffc,
> +#endif

These fields are no longer present in the machine description,
AFAICT.

Arnd

2010-12-15 15:38:41

[permalink] [raw]

Subject: Re: [PATCH 2/7] msm: Physical offset for MSM8960

On Wed, Dec 15, 2010 at 06:40:54AM -0800, Daniel Walker wrote:

> > > -#elif defined(CONFIG_ARCH_MSM8X60)
> > > +#elif defined(CONFIG_ARCH_MSM8X60) || defined(CONFIG_ARCH_MSM8960)
> >
> > I guess it's a matter of style, and what one is trying to emphasize.
> > Having each one listed makes it easier to change them individually.
> > The file is just a listing of the addresses of each chip, so I don't
> > see much reason to try and compact it.
>
> It just shows a deeper issue, that the namespace needs work. There's too
> much duplication here vs. 8x60 .. If you look over this whole patchset
> it looks very much like 8x60 was just copied over.

There's not very much copying here, in fact there isn't very much to
the 8960 support to begin with. Despite the confusing names, 8960 is
quite a bit different from 8[26]60. I agree we would probably be best
with different names, which might help make the difference clearer.

David

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2010-12-15 16:40:40

[permalink] [raw]

Subject: Re: [PATCH 1/7] msm: io: I/O register definitions for MSM8960

On Wednesday 15 December 2010, David Brown wrote:
>
> On Wed, Dec 15, 2010 at 04:31:11PM +0100, Arnd Bergmann wrote:
> > On Wednesday 15 December 2010, Stepan Moskovchenko wrote:
>
> > In this particular case, it's rather confusing, because one would assume
> > that MSM8960 is a subset of MSM8X60!
>
> Unfortunately, this is not the case, and I'm not sure what better name
> to use for MSM8X60. The MSM8X60 name covers MSM8260 and MSM8660, but
> MSM8960 is quite a bit different. Any ideas for better names?

No, you probably lose there, unless you can fall back to code names
instead of product numbers.

My point was really that they should not be exclusive, even if they
are rather different. If the code is structured in a more modular
way, you can turn all MSM/QSD options from the "Qualcomm MSM SoC Type"
choice into separate "bool" config options. You probably don't want
to do that now for all the existing ones, but I would suggest you
try not add more to the pile ;-).

Arnd

2010-12-15 17:53:47

by Steve Muckle

[permalink] [raw]

Subject: Re: [PATCH 2/7] msm: Physical offset for MSM8960

On 12/15/10 07:38, David Brown wrote:
> There's not very much copying here, in fact there isn't very much to
> the 8960 support to begin with. Despite the confusing names, 8960 is
> quite a bit different from 8[26]60. I agree we would probably be best
> with different names, which might help make the difference clearer.

A couple more comments here...

Currently it is the case that there is a lot of similarity between 8960
and 8660, however the two are expected to diverge as 8960 support
matures. This may include things like the physical offset so IMO it is
better to leave this things as per-ARCH rather than combining them.

During some previous discussions on the naming situation, one idea which
was floated was renaming 8x60 to 8660, which would help clarify the
difference from 8960. The only issue with that is that 8260, which is
for purposes of the kernel the same as 8660, would be left out and
probably just have to be mentioned in the Kconfig help text for 8660.

thanks,
Steve

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2010-12-15 17:55:49

by Daniel Walker

[permalink] [raw]

Subject: Re: [PATCH 2/7] msm: Physical offset for MSM8960

On Wed, 2010-12-15 at 07:38 -0800, David Brown wrote:
> On Wed, Dec 15, 2010 at 06:40:54AM -0800, Daniel Walker wrote:
>
> > > > -#elif defined(CONFIG_ARCH_MSM8X60)
> > > > +#elif defined(CONFIG_ARCH_MSM8X60) || defined(CONFIG_ARCH_MSM8960)
> > >
> > > I guess it's a matter of style, and what one is trying to emphasize.
> > > Having each one listed makes it easier to change them individually.
> > > The file is just a listing of the addresses of each chip, so I don't
> > > see much reason to try and compact it.
> >
> > It just shows a deeper issue, that the namespace needs work. There's too
> > much duplication here vs. 8x60 .. If you look over this whole patchset
> > it looks very much like 8x60 was just copied over.
>
> There's not very much copying here, in fact there isn't very much to
> the 8960 support to begin with. Despite the confusing names, 8960 is
> quite a bit different from 8[26]60. I agree we would probably be best
> with different names, which might help make the difference clearer.

The board file is very similar, plus the ifdefs. The code differences
are the io and irq's .. The naming issue and the duplication can be
simplified just by combining 8960 and 8660 .. If you create two new
Kconfig options,

config MACH_MSM8660
bool
config MACH_MSM8960
bool

and use ARCH_MSM8X60 for all the duplication .. That gives you the
ability to leverage the similarities, and enough macros to distinguish
between the two for the differences. If there's no duplication (but we
know there is) then you just don't use ARCH_MSM8X60. You could also have
board-msm8660.c and board-msm8960.c to hold board file differences and
board-msm8x60.c to hold the similarities.

I haven't explored this in great detail, but it seems like a better
naming scheme than what you have here.

Daniel

--

Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2010-12-15 18:07:42

by Steve Muckle

[permalink] [raw]

Subject: Re: [PATCH 2/7] msm: Physical offset for MSM8960

On 12/15/10 09:55, Daniel Walker wrote:
> The board file is very similar, plus the ifdefs. The code differences
> are the io and irq's .. The naming issue and the duplication can be

8x60 and 8960 are expected to diverge over time. It is not worth it to
try and make them common in this early stage where they are the same
simply because a very small amount of 8960 (and 8660 for that matter)
has been sent upstream.

> simplified just by combining 8960 and 8660 .. If you create two new
> Kconfig options,
>
> config MACH_MSM8660
> bool
> config MACH_MSM8960
> bool

We currently use ARCH_MSM* for SoCs, and MACH_* for boards based on
those SoCs. For this reason I think this scheme will be confusing and
lead to machine_is_() calls everywhere.

I suggest we rename 8x60 to 8660 (SteveMo's idea actually) if the
current naming is largely considered unacceptable.

thanks,
Steve

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2010-12-15 18:21:30

by Daniel Walker

[permalink] [raw]

Subject: Re: [PATCH 2/7] msm: Physical offset for MSM8960

On Wed, 2010-12-15 at 10:07 -0800, Steve Muckle wrote:
> On 12/15/10 09:55, Daniel Walker wrote:
> > The board file is very similar, plus the ifdefs. The code differences
> > are the io and irq's .. The naming issue and the duplication can be
>
> 8x60 and 8960 are expected to diverge over time. It is not worth it to
> try and make them common in this early stage where they are the same
> simply because a very small amount of 8960 (and 8660 for that matter)
> has been sent upstream.

My scheme should deal with that ..

> > simplified just by combining 8960 and 8660 .. If you create two new
> > Kconfig options,
> >
> > config MACH_MSM8660
> > bool
> > config MACH_MSM8960
> > bool
>
> We currently use ARCH_MSM* for SoCs, and MACH_* for boards based on
> those SoCs. For this reason I think this scheme will be confusing and
> lead to machine_is_() calls everywhere.

You just need to look at this a different way. It's actually not much
different than what we currently have, it just saves us the duplication
and eliminates the naming problem .. The current version shouldn't need
machine_is_() calls so then this new way shouldn't either. You just use
the ifdef's ..

> I suggest we rename 8x60 to 8660 (SteveMo's idea actually) if the
> current naming is largely considered unacceptable.

I wouldn't say it's unacceptable, it's just a open question if there's a
better way.

Daniel

--

Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2010-12-15 22:03:21

[permalink] [raw]

Subject: Re: [PATCH 1/7] msm: io: I/O register definitions for MSM8960

On Wed, Dec 15, 2010 at 05:40:24PM +0100, Arnd Bergmann wrote:

> My point was really that they should not be exclusive, even if they
> are rather different. If the code is structured in a more modular
> way, you can turn all MSM/QSD options from the "Qualcomm MSM SoC Type"
> choice into separate "bool" config options. You probably don't want
> to do that now for all the existing ones, but I would suggest you
> try not add more to the pile ;-).

It's kind of hard to do too much of this, though, until ARM kernels
can be relocated. They mostly all live at different base addresses
(and 8960 might also move). Throw CPU differences into the mix and it
gets messier.

I'm not saying it isn't solvable, but there are a lot of things that
need to be done to get there.

David

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2010-12-15 22:37:27

[permalink] [raw]

Subject: Re: [PATCH 1/7] msm: io: I/O register definitions for MSM8960

On Wednesday 15 December 2010, David Brown wrote:
>
> On Wed, Dec 15, 2010 at 05:40:24PM +0100, Arnd Bergmann wrote:
>
> > My point was really that they should not be exclusive, even if they
> > are rather different. If the code is structured in a more modular
> > way, you can turn all MSM/QSD options from the "Qualcomm MSM SoC Type"
> > choice into separate "bool" config options. You probably don't want
> > to do that now for all the existing ones, but I would suggest you
> > try not add more to the pile ;-).
>
> It's kind of hard to do too much of this, though, until ARM kernels
> can be relocated. They mostly all live at different base addresses
> (and 8960 might also move). Throw CPU differences into the mix and it
> gets messier.
>
> I'm not saying it isn't solvable, but there are a lot of things that
> need to be done to get there.

Yes, I understand that it's hard for many reasons, but my impression
is that there is a general agreement on the idea. As I said, I don't
expect you to fix it all at once, but it shouldn't be too hard
to take care when adding new code.

We already have infrastructure that deals with different CPU cores
in one kernel binary, at least from v5 to v7, and some platforms
like omap and realview can already be built for a variety of very
different machines without such problems.

Arnd

2010-12-17 00:17:01

[permalink] [raw]

Subject: Re: [PATCH 1/7] msm: io: I/O register definitions for MSM8960

On Wed, Dec 15, 2010 at 11:37:19PM +0100, Arnd Bergmann wrote:

> Yes, I understand that it's hard for many reasons, but my impression
> is that there is a general agreement on the idea. As I said, I don't
> expect you to fix it all at once, but it shouldn't be too hard
> to take care when adding new code.
>
> We already have infrastructure that deals with different CPU cores
> in one kernel binary, at least from v5 to v7, and some platforms
> like omap and realview can already be built for a variety of very
> different machines without such problems.

I agree with this goal, and I think I have a plan to get us there.

For example, the iomap constants. To fix this, this data needs to be
moved into platform data, or something similar. It seems to me to
make the most sense to move the individual devices out of the iomap
until at least the devices used so far on 8960 are all done
dynamically. Then at least these constants aren't needed for this
target.

There are similar things that need to be done for irqs, and timer
offsets.

I'm not sure really what to do about PHYS_OFFSET. This is kind of the
big thing that has kept us so far from making our SOCs multiply
selectable. I could move this into a Kconfig option, but it would
still need to be selected by the SOC. It is unfortunate that most of
our SOCs have different enough memory configurations that these are
mostly different. Even 8960/8660 will probably have future variants
that are at different addresses.

My question, then is, should we hold off on getting 8960 support into
the kernel until enough things are improved to get rid of the 8960
ifdefs? We can certainly do it that way, but it will keep the code
out of the kernel longer.

Thanks,
David

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2010-12-25 11:57:42

[permalink] [raw]

Subject: Re: [PATCH 1/7] msm: io: I/O register definitions for MSM8960

On Friday 17 December 2010, David Brown wrote:
> I agree with this goal, and I think I have a plan to get us there.
>
> For example, the iomap constants. To fix this, this data needs to be
> moved into platform data, or something similar. It seems to me to
> make the most sense to move the individual devices out of the iomap
> until at least the devices used so far on 8960 are all done
> dynamically. Then at least these constants aren't needed for this
> target.

This is something that would get a lot easier if we already had
device tree support, no idea if it's worth waiting for that for you.
Doing it with extensive platform data involves much of the same
work, but may be more of it.

> There are similar things that need to be done for irqs, and timer
> offsets.

Yes. Eric has spent a lot of time looking into all these issues,
he probably has a good overview of the potential problems.

> I'm not sure really what to do about PHYS_OFFSET. This is kind of the
> big thing that has kept us so far from making our SOCs multiply
> selectable. I could move this into a Kconfig option, but it would
> still need to be selected by the SOC. It is unfortunate that most of
> our SOCs have different enough memory configurations that these are
> mostly different. Even 8960/8660 will probably have future variants
> that are at different addresses.

I think there are people working on relocatable kernels already,
and we definitely need this for the other work in progress of
doing kernel binaries that work across different SoC families,
as well as for doing a single kernel that can be used both for
booting the system and for kdump.

You don't need to worry about PHYS_OFFSET at the platform level,
we'll get there in a few months for all ARM platforms.

> My question, then is, should we hold off on getting 8960 support into
> the kernel until enough things are improved to get rid of the 8960
> ifdefs? We can certainly do it that way, but it will keep the code
> out of the kernel longer.

My personal recommendation would be to fix all the places that you
can do without significant reworks of the existing code, and
just add TODO comments in the other places, so we can find them
easily. There is no reason to hold up merging the code too long for
this, but I wouldn't add code now that I know needs to be changed
soon to something that can already be done easily.

Arnd

2010-12-25 16:04:13

by Nicolas Pitre

[permalink] [raw]

Subject: Re: [PATCH 1/7] msm: io: I/O register definitions for MSM8960

On Fri, 24 Dec 2010, Arnd Bergmann wrote:

> On Friday 17 December 2010, David Brown wrote:
> > I'm not sure really what to do about PHYS_OFFSET. This is kind of the
> > big thing that has kept us so far from making our SOCs multiply
> > selectable. I could move this into a Kconfig option, but it would
> > still need to be selected by the SOC. It is unfortunate that most of
> > our SOCs have different enough memory configurations that these are
> > mostly different. Even 8960/8660 will probably have future variants
> > that are at different addresses.
>
> I think there are people working on relocatable kernels already,
> and we definitely need this for the other work in progress of
> doing kernel binaries that work across different SoC families,
> as well as for doing a single kernel that can be used both for
> booting the system and for kdump.
>
> You don't need to worry about PHYS_OFFSET at the platform level,
> we'll get there in a few months for all ARM platforms.

... or in a few days even. I'm currently working on the patch making
PHYS_OFFSET patched into the kernel at run time. I'm currently looking
at what is needed to make it work also with Thumb2.

Nicolas

2010-12-25 18:41:01