login
Search
Add initial support for the Qualcomm MSM8960 target. Stepan Moskovchenko (7): msm: io: I/O register definitions for MSM8960 msm: Physical offset for MSM8960 msm: irqs-8960: Interrupt map for MSM8960 msm: Board file for MSM8960 simulator msm: timer: Timer support for MSM8960 msm: Makefile cleanup msm: Build support for the MSM8960 target arch/arm/mach-msm/Kconfig | 16 ++ arch/arm/mach-msm/Makefile | 20 +- arch/arm/mach-msm/board-msm8960.c | 71 ++++++ arch/arm/mach-msm/include/mach/io.h | 1 + arch/arm/mach-msm/include/mach/irqs-8960.h | 293 +++++++++++++++++++++++ arch/arm/mach-msm/include/mach/irqs.h | 2 + arch/arm/mach-msm/include/mach/memory.h | 2 + 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 + arch/arm/mach-msm/timer.c | 3 +- 11 files changed, 466 insertions(+), 13 deletions(-) create mode 100644 arch/arm/mach-msm/board-msm8960.c create mode 100644 arch/arm/mach-msm/include/mach/irqs-8960.h create mode 100644 arch/arm/mach-msm/include/mach/msm_iomap-8960.h Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --
Add the register address definitions for the basic hardware blocks on the Qualcomm MSM8960 chip. Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org> --- 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 <swetland@google.com> + * + * 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 ...
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 --
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. --
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 --
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. --
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 --
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. --
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 Yes. Eric has spent a lot of time looking into all these issues, 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, 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 --
... 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 --
So where do we stand with: http://lists.arm.linux.org.uk/lurker/message/20101110.175549.62a0b058.en.html Is this something which should be queued for this merge window? --
I'm working on a patch series that includes a slightly modified version of the above plus a few fixes for issues that turned up during testing. I hope to have something for you to queue by tomorrow or tuesday. This is damn close to the merge window, but we don't have to turn it on by default. Nicolas --
Sounds like a good plan. I've already started going through the IO mapping defines to make them not-ifdef based. It's not that significant of a change. Of course, everyone is on break here who will be able to test things, so we'll have this stuff early January. 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. --
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 <stepanm@codeaurora.org> --- 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 ...
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 --
Clean up some of the conditionals in the Makefile in preparation for adding build support for MSM8960. Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org> --- 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. --
Modify the macros in the MSM timer driver to support the
MSM8960 chip.
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
---
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.
--
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 <stepanm@codeaurora.org> --- 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 ...
Add a basic board file needed to boot the kernel on the
MSM8960 simulator.
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
---
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 + ...These fields are no longer present in the machine description, AFAICT. Arnd --
Add the physical memory offset value for the Qualcomm MSM8960 chip. Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org> --- 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. --
Hello.
Why not:
-#elif defined(CONFIG_ARCH_MSM8X60)
+#elif defined(CONFIG_ARCH_MSM8X60) || defined(CONFIG_ARCH_MSM8960)
WBR, Sergei
--
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. --
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. --
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. --
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. --
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. --
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) 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. --
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 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. --
