* [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
From: Daniel Walker @ 2011-02-11 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8yaipwql1wf.fsf@huya.qualcomm.com>
On Fri, 2011-02-11 at 13:03 -0800, David Brown wrote:
> On Fri, Feb 11 2011, Steve Muckle wrote:
>
> > On 02/11/11 12:42, Daniel Walker wrote:
> >>> static struct resource msm_iommu_jpegd_resources[] = {
> >>> {
> >>> - .start = MSM_IOMMU_JPEGD_PHYS,
> >>> - .end = MSM_IOMMU_JPEGD_PHYS + MSM_IOMMU_JPEGD_SIZE - 1,
> >>> + .start = 0x07300000,
> >>> + .end = 0x07300000 + SZ_1M - 1,
> >>
> >> Looks worse .. Just put the macros into a static header file for both.
> >
> > Why bother defining macros for these if they only appear here? I don't
> > think that adds any value or readability - these addresses are clearly
> > the physical area for the msm_iommu_jpegd. It just makes it more
> > annoying to have to look up the values in a separate file if you are
> > wondering what they are.
>
> I want to chime in with a second on this. Defining names for constants
> serves several purposes:
>
> - It gives meaning to the constants.
>
> - It allows the definition to be centralized if the value is used in
> one place.
>
> If the constants are initializers in a table, it satisfies both of these
> reasons. Adding #defines for these constants does nothing other than
> cause an extra indirection that the reader of the code has to make.
>
> If they were used in more than one place, we could justify the
> definition, but in this case, the definition just obscures the code
> slightly.
It only obscures the constant, which no one really looks at anyway. in
general it's better design to hide constant like this, because people
don't work naturally with numbers like this.
A good example might be if all these constants are enumerated in a
header file, but aren't all used. In that case it would be fairly easy
to add a new resource without even know what the constant is just by
following the pattern.
I think in general this series just makes this iommu code very much
8660/8960 only code, but what about the potential next iteration of SoC
that uses very similar code to this with all new constants. So this
doesn't seem forward thinking to me.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
^ permalink raw reply
* [PATCH] mx31: add support for the bugbase 1.3 from buglabs
From: Denis 'GNUtoo' Carikli @ 2011-02-11 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297458388-23361-1-git-send-email-GNUtoo@no-log.org>
> diff --git a/arch/arm/plat-mxc/include/mach/uncompress.h b/arch/arm/plat-mxc/include/mach/uncompress.h
> index e634d6c..b45f534 100644
> --- a/arch/arm/plat-mxc/include/mach/uncompress.h
> +++ b/arch/arm/plat-mxc/include/mach/uncompress.h
> @@ -62,6 +62,7 @@ static inline void flush(void)
> #define MX2X_UART1_BASE_ADDR 0x1000a000
> #define MX3X_UART1_BASE_ADDR 0x43F90000
> #define MX3X_UART2_BASE_ADDR 0x43F94000
> +#define MX3X_UART5_BASE_ADDR 0x43FB4000
> #define MX51_UART1_BASE_ADDR 0x73fbc000
> #define MX50_UART1_BASE_ADDR 0x53fbc000
> #define MX53_UART1_BASE_ADDR 0x53fbc000
> @@ -102,6 +103,9 @@ static __inline__ void __arch_decomp_setup(unsigned long arch_id)
> case MACH_TYPE_MAGX_ZN5:
> uart_base = MX3X_UART2_BASE_ADDR;
> break;
> + case MACH_TYPE_BUG:
> + uart_base = MX3X_UART5_BASE_ADDR;
> + break;
> case MACH_TYPE_MX51_BABBAGE:
> case MACH_TYPE_EUKREA_CPUIMX51SD:
> case MACH_TYPE_MX51_3DS:
That seem not to crash, but I wonder if it's really useful:
Basically I see u-boot loading the kernel, then I have
> Uncompressing Linux...
Then I wait some seconds
Then I see that line beeing complretted with:
> done, booting the kernel.
Then the rest of the messages are displayed very fast,
along with initramfs loading messages and I finally get a shell.
Denis.
^ permalink raw reply
* [PATCH] mx31: add support for the bugbase 1.3 from buglabs
From: Denis 'GNUtoo' Carikli @ 2011-02-11 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297458388-23361-1-git-send-email-GNUtoo@no-log.org>
Sorry, the --subject-prefix="[PATCH V2]" was ignored
Denis.
^ permalink raw reply
* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
From: Russell King - ARM Linux @ 2011-02-11 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1102111543010.14920@xanadu.home>
On Fri, Feb 11, 2011 at 03:45:51PM -0500, Nicolas Pitre wrote:
> The patch below is making the code more straight forward regardless of
> any swp emulation issues.
I don't know where you get that idea from. What it does is make a kernel
built with a standard set of options have differing behaviour on v7 and
pre-v7 architectures.
On v7 architectures, the vectors page and user pages all become read only
to SVC mode. On pre-v7 architectures on the same kernel, they are read-
write to SVC mode.
What we have now is that these pages are only read-only when CPU domains
are turned off - for everything. So we know that if CPU domains are
enabled, it's read/write, otherwise it's read only. That's more
straight forward than what this patch creates IMHO.
^ permalink raw reply
* [PATCH] mx31: add support for the bugbase 1.3 from buglabs
From: Denis 'GNUtoo' Carikli @ 2011-02-11 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110211081050.GD27982@pengutronix.de>
This work was based on bug-linux-2.6.30.patch that can be found
in buglabs's svn here:
svn://bugcamp.net/bug/branches/izzy/experimental
Note that the hardware schematics and documentations can be obtained
here: http://www.bugcommunity.com/wiki/index.php/BUGbase
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
---
arch/arm/mach-mx3/Kconfig | 9 +++
arch/arm/mach-mx3/Makefile | 1 +
arch/arm/mach-mx3/mach-mx31bugbase.c | 75 +++++++++++++++++++++++++++
arch/arm/plat-mxc/include/mach/uncompress.h | 4 ++
4 files changed, 89 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mx3/mach-mx31bugbase.c
diff --git a/arch/arm/mach-mx3/Kconfig b/arch/arm/mach-mx3/Kconfig
index de80d98..4f57f13 100644
--- a/arch/arm/mach-mx3/Kconfig
+++ b/arch/arm/mach-mx3/Kconfig
@@ -199,6 +199,15 @@ config MACH_KZM_ARM11_01
Include support for KZM-ARM11-01. This includes specific
configurations for the board and its peripherals.
+config MACH_BUG
+ bool "Support Buglabs BUGBase platform"
+ select SOC_IMX31
+ select IMX_HAVE_PLATFORM_IMX_UART
+ default y
+ help
+ Include support for BUGBase 1.3 platform. This includes specific
+ configurations for the board and its peripherals.
+
config MACH_EUKREA_CPUIMX35
bool "Support Eukrea CPUIMX35 Platform"
select SOC_IMX35
diff --git a/arch/arm/mach-mx3/Makefile b/arch/arm/mach-mx3/Makefile
index bc7294f..98e5eb3 100644
--- a/arch/arm/mach-mx3/Makefile
+++ b/arch/arm/mach-mx3/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_MACH_PCM043) += mach-pcm043.o
obj-$(CONFIG_MACH_ARMADILLO5X0) += mach-armadillo5x0.o
obj-$(CONFIG_MACH_MX35_3DS) += mach-mx35_3ds.o
obj-$(CONFIG_MACH_KZM_ARM11_01) += mach-kzm_arm11_01.o
+obj-$(CONFIG_MACH_BUG) += mach-mx31bugbase.o
obj-$(CONFIG_MACH_EUKREA_CPUIMX35) += mach-cpuimx35.o
obj-$(CONFIG_MACH_EUKREA_MBIMXSD35_BASEBOARD) += eukrea_mbimxsd-baseboard.o
obj-$(CONFIG_MACH_VPR200) += mach-vpr200.o
diff --git a/arch/arm/mach-mx3/mach-mx31bugbase.c b/arch/arm/mach-mx3/mach-mx31bugbase.c
new file mode 100644
index 0000000..1d8ca1c
--- /dev/null
+++ b/arch/arm/mach-mx3/mach-mx31bugbase.c
@@ -0,0 +1,75 @@
+/*
+ * Copyright (C) 2000 Deep Blue Solutions Ltd
+ * Copyright (C) 2002 Shane Nay (shane at minirl.com)
+ * Copyright 2005-2007 Freescale Semiconductor, Inc. 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 as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+
+#include <mach/iomux-mx3.h>
+#include <mach/imx-uart.h>
+#include <mach/hardware.h>
+#include <mach/common.h>
+
+#include <asm/mach/time.h>
+#include <asm/mach/arch.h>
+#include <asm/mach-types.h>
+
+#include "devices-imx31.h"
+
+static struct imxuart_platform_data uart_pdata = {
+ .flags = IMXUART_HAVE_RTSCTS,
+};
+
+static unsigned int uart5_pins[] = {
+ MX31_PIN_PC_RST__CTS5,
+ MX31_PIN_PC_VS2__RTS5,
+ MX31_PIN_PC_BVD2__TXD5,
+ MX31_PIN_PC_BVD1__RXD5,
+};
+
+static inline void mx31bug_init_imx_uart(void)
+{
+ mxc_iomux_setup_multiple_pins(uart5_pins,
+ ARRAY_SIZE(uart5_pins), "uart-4");
+ imx31_add_imx_uart4(&uart_pdata);
+}
+
+/*!
+ * Board specific initialization.
+ */
+static void __init mx31bug_board_init(void)
+{
+ mx31bug_init_imx_uart();
+}
+
+
+static void __init mx31bug_timer_init(void)
+{
+ mx31_clocks_init(26000000);
+}
+
+static struct sys_timer mx31bug_timer = {
+ .init = mx31bug_timer_init,
+};
+
+MACHINE_START(BUG, "BugLabs BUGBase")
+ .boot_params = MX3x_PHYS_OFFSET + 0x100,
+ .map_io = mx31_map_io,
+ .init_early = imx31_init_early,
+ .init_irq = mx31_init_irq,
+ .timer = &mx31bug_timer,
+ .init_machine = mx31bug_board_init,
+MACHINE_END
diff --git a/arch/arm/plat-mxc/include/mach/uncompress.h b/arch/arm/plat-mxc/include/mach/uncompress.h
index e634d6c..b45f534 100644
--- a/arch/arm/plat-mxc/include/mach/uncompress.h
+++ b/arch/arm/plat-mxc/include/mach/uncompress.h
@@ -62,6 +62,7 @@ static inline void flush(void)
#define MX2X_UART1_BASE_ADDR 0x1000a000
#define MX3X_UART1_BASE_ADDR 0x43F90000
#define MX3X_UART2_BASE_ADDR 0x43F94000
+#define MX3X_UART5_BASE_ADDR 0x43FB4000
#define MX51_UART1_BASE_ADDR 0x73fbc000
#define MX50_UART1_BASE_ADDR 0x53fbc000
#define MX53_UART1_BASE_ADDR 0x53fbc000
@@ -102,6 +103,9 @@ static __inline__ void __arch_decomp_setup(unsigned long arch_id)
case MACH_TYPE_MAGX_ZN5:
uart_base = MX3X_UART2_BASE_ADDR;
break;
+ case MACH_TYPE_BUG:
+ uart_base = MX3X_UART5_BASE_ADDR;
+ break;
case MACH_TYPE_MX51_BABBAGE:
case MACH_TYPE_EUKREA_CPUIMX51SD:
case MACH_TYPE_MX51_3DS:
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
From: David Brown @ 2011-02-11 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D55A16A.7030300@codeaurora.org>
On Fri, Feb 11 2011, Steve Muckle wrote:
> On 02/11/11 12:42, Daniel Walker wrote:
>>> static struct resource msm_iommu_jpegd_resources[] = {
>>> {
>>> - .start = MSM_IOMMU_JPEGD_PHYS,
>>> - .end = MSM_IOMMU_JPEGD_PHYS + MSM_IOMMU_JPEGD_SIZE - 1,
>>> + .start = 0x07300000,
>>> + .end = 0x07300000 + SZ_1M - 1,
>>
>> Looks worse .. Just put the macros into a static header file for both.
>
> Why bother defining macros for these if they only appear here? I don't
> think that adds any value or readability - these addresses are clearly
> the physical area for the msm_iommu_jpegd. It just makes it more
> annoying to have to look up the values in a separate file if you are
> wondering what they are.
I want to chime in with a second on this. Defining names for constants
serves several purposes:
- It gives meaning to the constants.
- It allows the definition to be centralized if the value is used in
one place.
If the constants are initializers in a table, it satisfies both of these
reasons. Adding #defines for these constants does nothing other than
cause an extra indirection that the reader of the code has to make.
If they were used in more than one place, we could justify the
definition, but in this case, the definition just obscures the code
slightly.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
From: Daniel Walker @ 2011-02-11 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D55A372.9090705@codeaurora.org>
On Fri, 2011-02-11 at 13:00 -0800, Steve Muckle wrote:
> On 02/11/11 12:58, Daniel Walker wrote:
> > On Fri, 2011-02-11 at 12:51 -0800, Steve Muckle wrote:
> >> On 02/11/11 12:42, Daniel Walker wrote:
> >>>> static struct resource msm_iommu_jpegd_resources[] = {
> >>>> {
> >>>> - .start = MSM_IOMMU_JPEGD_PHYS,
> >>>> - .end = MSM_IOMMU_JPEGD_PHYS + MSM_IOMMU_JPEGD_SIZE - 1,
> >>>> + .start = 0x07300000,
> >>>> + .end = 0x07300000 + SZ_1M - 1,
> >>>
> >>> Looks worse .. Just put the macros into a static header file for both.
> >>
> >> Why bother defining macros for these if they only appear here? I don't
> >> think that adds any value or readability - these addresses are clearly
> >> the physical area for the msm_iommu_jpegd. It just makes it more
> >> annoying to have to look up the values in a separate file if you are
> >> wondering what they are.
> >
> > So your saying if you look at the number 0x07300000 you instantly know
> > that this JPEGD?
>
> Yes, because it's the start address for the msm_iommu_jpegd resource.
Yeah I guess that's true .. I still think it's better design not to do
it this way.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
^ permalink raw reply
* [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
From: Steve Muckle @ 2011-02-11 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297457899.4852.14.camel@m0nster>
On 02/11/11 12:58, Daniel Walker wrote:
> On Fri, 2011-02-11 at 12:51 -0800, Steve Muckle wrote:
>> On 02/11/11 12:42, Daniel Walker wrote:
>>>> static struct resource msm_iommu_jpegd_resources[] = {
>>>> {
>>>> - .start = MSM_IOMMU_JPEGD_PHYS,
>>>> - .end = MSM_IOMMU_JPEGD_PHYS + MSM_IOMMU_JPEGD_SIZE - 1,
>>>> + .start = 0x07300000,
>>>> + .end = 0x07300000 + SZ_1M - 1,
>>>
>>> Looks worse .. Just put the macros into a static header file for both.
>>
>> Why bother defining macros for these if they only appear here? I don't
>> think that adds any value or readability - these addresses are clearly
>> the physical area for the msm_iommu_jpegd. It just makes it more
>> annoying to have to look up the values in a separate file if you are
>> wondering what they are.
>
> So your saying if you look at the number 0x07300000 you instantly know
> that this JPEGD?
Yes, because it's the start address for the msm_iommu_jpegd resource.
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.
^ permalink raw reply
* [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
From: Daniel Walker @ 2011-02-11 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D55A16A.7030300@codeaurora.org>
On Fri, 2011-02-11 at 12:51 -0800, Steve Muckle wrote:
> On 02/11/11 12:42, Daniel Walker wrote:
> >> static struct resource msm_iommu_jpegd_resources[] = {
> >> {
> >> - .start = MSM_IOMMU_JPEGD_PHYS,
> >> - .end = MSM_IOMMU_JPEGD_PHYS + MSM_IOMMU_JPEGD_SIZE - 1,
> >> + .start = 0x07300000,
> >> + .end = 0x07300000 + SZ_1M - 1,
> >
> > Looks worse .. Just put the macros into a static header file for both.
>
> Why bother defining macros for these if they only appear here? I don't
> think that adds any value or readability - these addresses are clearly
> the physical area for the msm_iommu_jpegd. It just makes it more
> annoying to have to look up the values in a separate file if you are
> wondering what they are.
So your saying if you look at the number 0x07300000 you instantly know
that this JPEGD? What if I pick a random other kernel developer do you
think they would instantly know that? I have no idea what 0x07300000 is.
Also if it's in a header you could ifdef them with out touching the C
file, which is just forward looking.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
^ permalink raw reply
* [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
From: Steve Muckle @ 2011-02-11 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297456934.4852.11.camel@m0nster>
On 02/11/11 12:42, Daniel Walker wrote:
>> static struct resource msm_iommu_jpegd_resources[] = {
>> {
>> - .start = MSM_IOMMU_JPEGD_PHYS,
>> - .end = MSM_IOMMU_JPEGD_PHYS + MSM_IOMMU_JPEGD_SIZE - 1,
>> + .start = 0x07300000,
>> + .end = 0x07300000 + SZ_1M - 1,
>
> Looks worse .. Just put the macros into a static header file for both.
Why bother defining macros for these if they only appear here? I don't
think that adds any value or readability - these addresses are clearly
the physical area for the msm_iommu_jpegd. It just makes it more
annoying to have to look up the values in a separate file if you are
wondering what they are.
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.
^ permalink raw reply
* [PATCH 00/14] Fix issues with ARMv6+v6k+v7 kernels
From: Nicolas Pitre @ 2011-02-11 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297343555.9306.9.camel@e102109-lin.cambridge.arm.com>
On Thu, 10 Feb 2011, Catalin Marinas wrote:
> On Thu, 2011-02-10 at 13:04 +0000, Russell King - ARM Linux wrote:
> > On Wed, Feb 09, 2011 at 10:01:33AM +0000, Catalin Marinas wrote:
> > > Could we make the domains usage a run-time feature based on the
> > > architecture version? For ARMv7, we need to have the vectors page
> > > read-only anyway if the SWP emulation is enabled (and I posted a
> > > simple patch in a reply to your email).
> > >
> > > The issue I see is that ARM11MPCore is reported as v7 though we still
> > > use domains on this processor (we could always remove the domains if
> > > TLS register is available or use some more precise architecture
> > > version identification).
> >
> > We could also do the below, which I think is more logical - SWP emulation
> > requires that CPU domains aren't enabled, so let's make that explicit
> > in the Kconfig.
>
> This may work but it is to restrictive IMHO. SWP emulation only requires
> that RO user pages are also RO for the kernel. And there is a simple fix
> for this:
>
The patch below is making the code more straight forward regardless of
any swp emulation issues.
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index ee57640..6e0b349 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -758,17 +758,21 @@ static void __init kuser_get_tls_init(unsigned long vectors)
>
> void __init early_trap_init(void)
> {
> -#if defined(CONFIG_CPU_USE_DOMAINS)
> - unsigned long vectors = CONFIG_VECTORS_BASE;
> -#else
> - unsigned long vectors = (unsigned long)vectors_page;
> -#endif
> + unsigned long vectors;
> extern char __stubs_start[], __stubs_end[];
> extern char __vectors_start[], __vectors_end[];
> extern char __kuser_helper_start[], __kuser_helper_end[];
> int kuser_sz = __kuser_helper_end - __kuser_helper_start;
>
> /*
> + * On ARMv7, user RO pages are mapped as kernel RO.
> + */
> + if (cpu_architecture() >= 7)
> + vectors = (unsigned long)vectors_page;
> + else
> + vectors = CONFIG_VECTORS_BASE;
> +
> + /*
> * Copy the vectors, stubs and kuser helpers (in entry-armv.S)
> * into the vector page, mapped at 0xffff0000, and ensure these
> * are visible to the instruction stream.
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index 0c1172b..5f51592 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -146,11 +146,6 @@ ENTRY(cpu_v7_set_pte_ext)
>
> tst r1, #L_PTE_USER
> orrne r3, r3, #PTE_EXT_AP1
> -#ifdef CONFIG_CPU_USE_DOMAINS
> - @ allow kernel read/write access to read-only user pages
> - tstne r3, #PTE_EXT_APX
> - bicne r3, r3, #PTE_EXT_APX | PTE_EXT_AP0
> -#endif
>
> tst r1, #L_PTE_XN
> orrne r3, r3, #PTE_EXT_XN
>
>
> --
> Catalin
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
From: Daniel Walker @ 2011-02-11 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297456098-3241-2-git-send-email-stepanm@codeaurora.org>
On Fri, 2011-02-11 at 12:28 -0800, Stepan Moskovchenko wrote:
> Make the IOMMU platform data target-independent in
> preparation for adding MSM8960 IOMMU support. The IOMMU
> configuration on MSM8x60 and MSM8960 is identical and the
> same platform data can be used for both.
>
> Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
> ---
> arch/arm/mach-msm/Makefile | 4 +-
> .../{devices-msm8x60-iommu.c => devices-iommu.c} | 54 +++++++++----------
> arch/arm/mach-msm/include/mach/msm_iomap-8x60.h | 36 -------------
> 3 files changed, 28 insertions(+), 66 deletions(-)
> rename arch/arm/mach-msm/{devices-msm8x60-iommu.c => devices-iommu.c} (93%)
>
> diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
> index 81f4811..2099c97 100644
> --- a/arch/arm/mach-msm/Makefile
> +++ b/arch/arm/mach-msm/Makefile
> @@ -4,12 +4,12 @@ obj-$(CONFIG_DEBUG_FS) += clock-debug.o
> endif
>
> obj-$(CONFIG_MSM_VIC) += irq-vic.o
> -obj-$(CONFIG_MSM_IOMMU) += iommu.o iommu_dev.o
> +obj-$(CONFIG_MSM_IOMMU) += iommu.o iommu_dev.o devices-iommu.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 devices-msm8x60-iommu.o
> +obj-$(CONFIG_ARCH_MSM8X60) += clock-dummy.o
> obj-$(CONFIG_ARCH_MSM8960) += clock-dummy.o
>
> obj-$(CONFIG_MSM_PROC_COMM) += proc_comm.o clock-pcom.o vreg.o
> diff --git a/arch/arm/mach-msm/devices-msm8x60-iommu.c b/arch/arm/mach-msm/devices-iommu.c
> similarity index 93%
> rename from arch/arm/mach-msm/devices-msm8x60-iommu.c
> rename to arch/arm/mach-msm/devices-iommu.c
> index f9e7bd3..c0206b7 100644
> --- a/arch/arm/mach-msm/devices-msm8x60-iommu.c
> +++ b/arch/arm/mach-msm/devices-iommu.c
> @@ -1,4 +1,4 @@
> -/* Copyright (c) 2010, Code Aurora Forum. All rights reserved.
> +/* Copyright (c) 2010-2011, 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
> @@ -18,15 +18,13 @@
> #include <linux/kernel.h>
> #include <linux/platform_device.h>
> #include <linux/bootmem.h>
> -
> -#include <mach/msm_iomap-8x60.h>
> -#include <mach/irqs-8x60.h>
> +#include <mach/irqs.h>
> #include <mach/iommu.h>
>
> static struct resource msm_iommu_jpegd_resources[] = {
> {
> - .start = MSM_IOMMU_JPEGD_PHYS,
> - .end = MSM_IOMMU_JPEGD_PHYS + MSM_IOMMU_JPEGD_SIZE - 1,
> + .start = 0x07300000,
> + .end = 0x07300000 + SZ_1M - 1,
Looks worse .. Just put the macros into a static header file for both.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
^ permalink raw reply
* [PATCH 1/3] msm: iommu: Create a Kconfig item for the IOMMU driver
From: Daniel Walker @ 2011-02-11 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297456098-3241-1-git-send-email-stepanm@codeaurora.org>
On Fri, 2011-02-11 at 12:28 -0800, Stepan Moskovchenko wrote:
> +config MSM_IOMMU
> + bool "MSM IOMMU Support"
> + depends on ARCH_MSM8X60
> + select IOMMU_API
> + default n
> + help
> + Support for the IOMMUs found on certain Qualcomm SOCs.
> + These IOMMUs allow virtualization of the address space used by most
> + cores within the multimedia subsystem.
> +
> + If unsure, say N here.
I think you should just make this a hidden option, unless there is a
good reason why any given users might want to turn this off.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
^ permalink raw reply
* [PATCH] PM: Allow pm_runtime_suspend() to succeed during system suspend
From: Kevin Hilman @ 2011-02-11 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102112100.23996.rjw@sisk.pl>
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Monday, January 31, 2011, Rafael J. Wysocki wrote:
>> On Monday, January 31, 2011, Alan Stern wrote:
>> > On Mon, 31 Jan 2011, Kevin Hilman wrote:
>> >
>> > > I understand how this works, but frankly I'm still a bit fuzzy on why.
>> > >
>> > > I guess I'm still missing a good understanding of what "interfering with a
>> > > system power transition" means, and why a runtime suspend qualifies as
>> > > interfering but not a runtime resume.
>> >
>> > These are good questions. Rafael implemented this design originally;
>> > my contribution was only to warn him of the potential for problems.
>> > Therefore he should explain the rationale for the design.
>>
>> The reason why runtime resume is allowed during system power transitions is
>> because in some cases during system suspend we simply have to resume devices
>> that were previously runtime-suspended (for example, the PCI bus type does
>> that).
>>
>> The reason why runtime suspend is not allowed during system power transitions
>> if the following race:
>>
>> - A device has been suspended via a system suspend callback.
>> - The runtime PM framework executes a (scheduled) suspend on that device,
>> not knowing that it's already been suspended, which potentially results in
>> accessing the device's registers in a low-power state.
>>
>> Now, it can be avoided if every driver does the right thing and checks whether
>> the device is already suspended in its runtime suspend callback, but that would
>> kind of defeat the purpose of the runtime PM framework, at least partially.
>
> In fact, I've just realized that the above race cannot really occur, because
> pm_wq is freezable, so I'm proposing the following change.
>
> Of course, it still doesn't prevent user space from disabling the runtime PM
> framework's helpers via /sys/devices/.../power/control.
>
> Thanks,
> Rafael
>
>
> ---
> From: Rafael J. Wysocki <rjw@sisk.pl>
> Subject: PM: Allow pm_runtime_suspend() to succeed during system suspend
>
> The dpm_prepare() function increments the runtime PM reference
> counters of all devices to prevent pm_runtime_suspend() from
> executing subsystem-level callbacks. However, this was supposed to
> guard against a specific race condition that cannot happen, because
> the power management workqueue is freezable, so pm_runtime_suspend()
> can only be called synchronously during system suspend and we can
> rely on subsystems and device drivers to avoid doing that
> unnecessarily.
>
> Make dpm_prepare() drop the runtime PM reference to each device
> after making sure that runtime resume is not pending for it.
>
> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> ---
Yes!
Acked-by: Kevin Hilman <khilman@ti.com>
> drivers/base/power/main.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> Index: linux-2.6/drivers/base/power/main.c
> ===================================================================
> --- linux-2.6.orig/drivers/base/power/main.c
> +++ linux-2.6/drivers/base/power/main.c
> @@ -669,7 +669,6 @@ static void dpm_complete(pm_message_t st
> mutex_unlock(&dpm_list_mtx);
>
> device_complete(dev, state);
> - pm_runtime_put_sync(dev);
>
> mutex_lock(&dpm_list_mtx);
> put_device(dev);
> @@ -1005,12 +1004,9 @@ static int dpm_prepare(pm_message_t stat
> if (pm_runtime_barrier(dev) && device_may_wakeup(dev))
> pm_wakeup_event(dev, 0);
>
> - if (pm_wakeup_pending()) {
> - pm_runtime_put_sync(dev);
> - error = -EBUSY;
> - } else {
> - error = device_prepare(dev, state);
> - }
> + pm_runtime_put_sync(dev);
> + error = pm_wakeup_pending() ?
> + -EBUSY : device_prepare(dev, state);
>
> mutex_lock(&dpm_list_mtx);
> if (error) {
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] PM: Allow pm_runtime_suspend() to succeed during system suspend
From: Alan Stern @ 2011-02-11 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102112100.23996.rjw@sisk.pl>
On Fri, 11 Feb 2011, Rafael J. Wysocki wrote:
> > The reason why runtime suspend is not allowed during system power transitions
> > if the following race:
> >
> > - A device has been suspended via a system suspend callback.
> > - The runtime PM framework executes a (scheduled) suspend on that device,
> > not knowing that it's already been suspended, which potentially results in
> > accessing the device's registers in a low-power state.
> >
> > Now, it can be avoided if every driver does the right thing and checks whether
> > the device is already suspended in its runtime suspend callback, but that would
> > kind of defeat the purpose of the runtime PM framework, at least partially.
>
> In fact, I've just realized that the above race cannot really occur, because
> pm_wq is freezable, so I'm proposing the following change.
Yes, I had reached essentially the same conclusion. Of course, there
may still be other kernel threads running or interrupt handlers that
can interfere. It's probably okay to assume that drivers will handle
these things.
> Of course, it still doesn't prevent user space from disabling the runtime PM
> framework's helpers via /sys/devices/.../power/control.
True. So in the end this won't make much difference, but we might as
well do it.
Alan Stern
^ permalink raw reply
* [PATCH 3/3] msm: iommu: Enable IOMMU support for MSM8960
From: Stepan Moskovchenko @ 2011-02-11 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297456098-3241-1-git-send-email-stepanm@codeaurora.org>
Allow IOMMU to be selected for MSM8960 now that the
platform data has been generalized.
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
---
arch/arm/mach-msm/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 32b9d1f..997c5bd 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -150,7 +150,7 @@ endmenu
config MSM_IOMMU
bool "MSM IOMMU Support"
- depends on ARCH_MSM8X60
+ depends on ARCH_MSM8X60 || ARCH_MSM8960
select IOMMU_API
default n
help
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
From: Stepan Moskovchenko @ 2011-02-11 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297456098-3241-1-git-send-email-stepanm@codeaurora.org>
Make the IOMMU platform data target-independent in
preparation for adding MSM8960 IOMMU support. The IOMMU
configuration on MSM8x60 and MSM8960 is identical and the
same platform data can be used for both.
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
---
arch/arm/mach-msm/Makefile | 4 +-
.../{devices-msm8x60-iommu.c => devices-iommu.c} | 54 +++++++++----------
arch/arm/mach-msm/include/mach/msm_iomap-8x60.h | 36 -------------
3 files changed, 28 insertions(+), 66 deletions(-)
rename arch/arm/mach-msm/{devices-msm8x60-iommu.c => devices-iommu.c} (93%)
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index 81f4811..2099c97 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -4,12 +4,12 @@ obj-$(CONFIG_DEBUG_FS) += clock-debug.o
endif
obj-$(CONFIG_MSM_VIC) += irq-vic.o
-obj-$(CONFIG_MSM_IOMMU) += iommu.o iommu_dev.o
+obj-$(CONFIG_MSM_IOMMU) += iommu.o iommu_dev.o devices-iommu.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 devices-msm8x60-iommu.o
+obj-$(CONFIG_ARCH_MSM8X60) += clock-dummy.o
obj-$(CONFIG_ARCH_MSM8960) += clock-dummy.o
obj-$(CONFIG_MSM_PROC_COMM) += proc_comm.o clock-pcom.o vreg.o
diff --git a/arch/arm/mach-msm/devices-msm8x60-iommu.c b/arch/arm/mach-msm/devices-iommu.c
similarity index 93%
rename from arch/arm/mach-msm/devices-msm8x60-iommu.c
rename to arch/arm/mach-msm/devices-iommu.c
index f9e7bd3..c0206b7 100644
--- a/arch/arm/mach-msm/devices-msm8x60-iommu.c
+++ b/arch/arm/mach-msm/devices-iommu.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2010, Code Aurora Forum. All rights reserved.
+/* Copyright (c) 2010-2011, 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
@@ -18,15 +18,13 @@
#include <linux/kernel.h>
#include <linux/platform_device.h>
#include <linux/bootmem.h>
-
-#include <mach/msm_iomap-8x60.h>
-#include <mach/irqs-8x60.h>
+#include <mach/irqs.h>
#include <mach/iommu.h>
static struct resource msm_iommu_jpegd_resources[] = {
{
- .start = MSM_IOMMU_JPEGD_PHYS,
- .end = MSM_IOMMU_JPEGD_PHYS + MSM_IOMMU_JPEGD_SIZE - 1,
+ .start = 0x07300000,
+ .end = 0x07300000 + SZ_1M - 1,
.name = "physbase",
.flags = IORESOURCE_MEM,
},
@@ -46,8 +44,8 @@ static struct resource msm_iommu_jpegd_resources[] = {
static struct resource msm_iommu_vpe_resources[] = {
{
- .start = MSM_IOMMU_VPE_PHYS,
- .end = MSM_IOMMU_VPE_PHYS + MSM_IOMMU_VPE_SIZE - 1,
+ .start = 0x07400000,
+ .end = 0x07400000 + SZ_1M - 1,
.name = "physbase",
.flags = IORESOURCE_MEM,
},
@@ -67,8 +65,8 @@ static struct resource msm_iommu_vpe_resources[] = {
static struct resource msm_iommu_mdp0_resources[] = {
{
- .start = MSM_IOMMU_MDP0_PHYS,
- .end = MSM_IOMMU_MDP0_PHYS + MSM_IOMMU_MDP0_SIZE - 1,
+ .start = 0x07500000,
+ .end = 0x07500000 + SZ_1M - 1,
.name = "physbase",
.flags = IORESOURCE_MEM,
},
@@ -88,8 +86,8 @@ static struct resource msm_iommu_mdp0_resources[] = {
static struct resource msm_iommu_mdp1_resources[] = {
{
- .start = MSM_IOMMU_MDP1_PHYS,
- .end = MSM_IOMMU_MDP1_PHYS + MSM_IOMMU_MDP1_SIZE - 1,
+ .start = 0x07600000,
+ .end = 0x07600000 + SZ_1M - 1,
.name = "physbase",
.flags = IORESOURCE_MEM,
},
@@ -109,8 +107,8 @@ static struct resource msm_iommu_mdp1_resources[] = {
static struct resource msm_iommu_rot_resources[] = {
{
- .start = MSM_IOMMU_ROT_PHYS,
- .end = MSM_IOMMU_ROT_PHYS + MSM_IOMMU_ROT_SIZE - 1,
+ .start = 0x07700000,
+ .end = 0x07700000 + SZ_1M - 1,
.name = "physbase",
.flags = IORESOURCE_MEM,
},
@@ -130,8 +128,8 @@ static struct resource msm_iommu_rot_resources[] = {
static struct resource msm_iommu_ijpeg_resources[] = {
{
- .start = MSM_IOMMU_IJPEG_PHYS,
- .end = MSM_IOMMU_IJPEG_PHYS + MSM_IOMMU_IJPEG_SIZE - 1,
+ .start = 0x07800000,
+ .end = 0x07800000 + SZ_1M - 1,
.name = "physbase",
.flags = IORESOURCE_MEM,
},
@@ -151,8 +149,8 @@ static struct resource msm_iommu_ijpeg_resources[] = {
static struct resource msm_iommu_vfe_resources[] = {
{
- .start = MSM_IOMMU_VFE_PHYS,
- .end = MSM_IOMMU_VFE_PHYS + MSM_IOMMU_VFE_SIZE - 1,
+ .start = 0x07900000,
+ .end = 0x07900000 + SZ_1M - 1,
.name = "physbase",
.flags = IORESOURCE_MEM,
},
@@ -172,8 +170,8 @@ static struct resource msm_iommu_vfe_resources[] = {
static struct resource msm_iommu_vcodec_a_resources[] = {
{
- .start = MSM_IOMMU_VCODEC_A_PHYS,
- .end = MSM_IOMMU_VCODEC_A_PHYS + MSM_IOMMU_VCODEC_A_SIZE - 1,
+ .start = 0x07A00000,
+ .end = 0x07A00000 + SZ_1M - 1,
.name = "physbase",
.flags = IORESOURCE_MEM,
},
@@ -193,8 +191,8 @@ static struct resource msm_iommu_vcodec_a_resources[] = {
static struct resource msm_iommu_vcodec_b_resources[] = {
{
- .start = MSM_IOMMU_VCODEC_B_PHYS,
- .end = MSM_IOMMU_VCODEC_B_PHYS + MSM_IOMMU_VCODEC_B_SIZE - 1,
+ .start = 0x07B00000,
+ .end = 0x07B00000 + SZ_1M - 1,
.name = "physbase",
.flags = IORESOURCE_MEM,
},
@@ -214,8 +212,8 @@ static struct resource msm_iommu_vcodec_b_resources[] = {
static struct resource msm_iommu_gfx3d_resources[] = {
{
- .start = MSM_IOMMU_GFX3D_PHYS,
- .end = MSM_IOMMU_GFX3D_PHYS + MSM_IOMMU_GFX3D_SIZE - 1,
+ .start = 0x07C00000,
+ .end = 0x07C00000 + SZ_1M - 1,
.name = "physbase",
.flags = IORESOURCE_MEM,
},
@@ -235,8 +233,8 @@ static struct resource msm_iommu_gfx3d_resources[] = {
static struct resource msm_iommu_gfx2d0_resources[] = {
{
- .start = MSM_IOMMU_GFX2D0_PHYS,
- .end = MSM_IOMMU_GFX2D0_PHYS + MSM_IOMMU_GFX2D0_SIZE - 1,
+ .start = 0x07D00000,
+ .end = 0x07D00000 + SZ_1M - 1,
.name = "physbase",
.flags = IORESOURCE_MEM,
},
@@ -256,8 +254,8 @@ static struct resource msm_iommu_gfx2d0_resources[] = {
static struct resource msm_iommu_gfx2d1_resources[] = {
{
- .start = MSM_IOMMU_GFX2D1_PHYS,
- .end = MSM_IOMMU_GFX2D1_PHYS + MSM_IOMMU_GFX2D1_SIZE - 1,
+ .start = 0x07E00000,
+ .end = 0x07E00000 + SZ_1M - 1,
.name = "physbase",
.flags = IORESOURCE_MEM,
},
diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h b/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h
index 5bd18db..3b19b8f 100644
--- a/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h
+++ b/arch/arm/mach-msm/include/mach/msm_iomap-8x60.h
@@ -62,40 +62,4 @@
#define MSM8X60_TMR0_PHYS 0x02040000
#define MSM8X60_TMR0_SIZE SZ_4K
-#define MSM_IOMMU_JPEGD_PHYS 0x07300000
-#define MSM_IOMMU_JPEGD_SIZE SZ_1M
-
-#define MSM_IOMMU_VPE_PHYS 0x07400000
-#define MSM_IOMMU_VPE_SIZE SZ_1M
-
-#define MSM_IOMMU_MDP0_PHYS 0x07500000
-#define MSM_IOMMU_MDP0_SIZE SZ_1M
-
-#define MSM_IOMMU_MDP1_PHYS 0x07600000
-#define MSM_IOMMU_MDP1_SIZE SZ_1M
-
-#define MSM_IOMMU_ROT_PHYS 0x07700000
-#define MSM_IOMMU_ROT_SIZE SZ_1M
-
-#define MSM_IOMMU_IJPEG_PHYS 0x07800000
-#define MSM_IOMMU_IJPEG_SIZE SZ_1M
-
-#define MSM_IOMMU_VFE_PHYS 0x07900000
-#define MSM_IOMMU_VFE_SIZE SZ_1M
-
-#define MSM_IOMMU_VCODEC_A_PHYS 0x07A00000
-#define MSM_IOMMU_VCODEC_A_SIZE SZ_1M
-
-#define MSM_IOMMU_VCODEC_B_PHYS 0x07B00000
-#define MSM_IOMMU_VCODEC_B_SIZE SZ_1M
-
-#define MSM_IOMMU_GFX3D_PHYS 0x07C00000
-#define MSM_IOMMU_GFX3D_SIZE SZ_1M
-
-#define MSM_IOMMU_GFX2D0_PHYS 0x07D00000
-#define MSM_IOMMU_GFX2D0_SIZE SZ_1M
-
-#define MSM_IOMMU_GFX2D1_PHYS 0x07E00000
-#define MSM_IOMMU_GFX2D1_SIZE SZ_1M
-
#endif
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 1/3] msm: iommu: Create a Kconfig item for the IOMMU driver
From: Stepan Moskovchenko @ 2011-02-11 20:28 UTC (permalink / raw)
To: linux-arm-kernel
Break the IOMMU driver out as a Kconfig item. Initially it
was decided to always build this in for 8x60, but this
driver is not strictly necessary and should be optionally
selectable.
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
---
arch/arm/mach-msm/Kconfig | 13 ++++++++++++-
arch/arm/mach-msm/Makefile | 3 ++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index df9d74e..32b9d1f 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -45,7 +45,6 @@ config ARCH_MSM8X60
select CPU_V7
select MSM_V2_TLMM
select MSM_GPIOMUX
- select IOMMU_API
select MSM_SCM if SMP
config ARCH_MSM8960
@@ -149,6 +148,18 @@ config MACH_MSM8960_RUMI3
endmenu
+config MSM_IOMMU
+ bool "MSM IOMMU Support"
+ depends on ARCH_MSM8X60
+ select IOMMU_API
+ default n
+ help
+ Support for the IOMMUs found on certain Qualcomm SOCs.
+ These IOMMUs allow virtualization of the address space used by most
+ cores within the multimedia subsystem.
+
+ If unsure, say N here.
+
config IOMMU_PGTABLES_L2
def_bool y
depends on ARCH_MSM8X60 && MMU && SMP && CPU_DCACHE_DISABLE=n
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index ea8c74f..81f4811 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -4,11 +4,12 @@ obj-$(CONFIG_DEBUG_FS) += clock-debug.o
endif
obj-$(CONFIG_MSM_VIC) += irq-vic.o
+obj-$(CONFIG_MSM_IOMMU) += iommu.o iommu_dev.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_ARCH_MSM8X60) += clock-dummy.o devices-msm8x60-iommu.o
obj-$(CONFIG_ARCH_MSM8960) += clock-dummy.o
obj-$(CONFIG_MSM_PROC_COMM) += proc_comm.o clock-pcom.o vreg.o
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 1/7] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Arnd Bergmann @ 2011-02-11 20:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110212005506.GE9289@S2100-06.ap.freescale.net>
On Saturday 12 February 2011 01:55:07 Shawn Guo wrote:
> On Fri, Feb 11, 2011 at 04:51:35PM +0100, Arnd Bergmann wrote:
> > I have not looked much at other dmaengine drivers, but I'd be
> > surprised if they require the device driver to be written
> > for a specific implementation. If that was the case, you would
> > not even need a dmaengine API but could just as well write
> > to the DMA controller registers from the device driver directly.
> >
> We need a specific implementation, but it's not so specific that we
> have to access dma controller directly. Even it is, we still need
> an API/interface, as there are so many client devices need to do the
> same thing, right? ;)
I looked at all mmc drivers that use the dmaengine API:
atmel-mci.c does the same as what you propose here, while sh_mmcif.c
and tmio_mmc.c more or less do what I'm suggesting you do instead.
Looking at sh_mmcif:
host->chan_tx = dma_request_channel(mask, sh_mmcif_filter,
&pdata->dma->chan_priv_tx);
This is the only place where dma engine specific data is used
in the driver, and chan_priv_tx is part of the platform data, so the
mmc driver can simply pass it down as a void pointer without knowing
the type. The platform data as defined in the machine file ties
both the dma controller and the mmc device together, but neither
of the two drivers needs to know anything about the implementation
of the other.
> So it should be something like the following?
>
> spin_lock(&host->lock);
>
> stat = readl(host->base + HW_SSP_CTRL1);
> writel(stat & MXS_MMC_IRQ_BITS,
> host->base + HW_SSP_CTRL1 + MXS_CLR_ADDR);
>
> [...]
>
> if ((stat & BM_SSP_CTRL1_SDIO_IRQ) && (stat & BM_SSP_CTRL1_SDIO_IRQ_EN))
> mmc_signal_sdio_irq(host->mmc);
>
> spin_unlock(&host->lock);
>
Yes, this looks correct to me now.
Arnd
^ permalink raw reply
* [PATCH] PM: Allow pm_runtime_suspend() to succeed during system suspend
From: Rafael J. Wysocki @ 2011-02-11 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201101311919.49225.rjw@sisk.pl>
On Monday, January 31, 2011, Rafael J. Wysocki wrote:
> On Monday, January 31, 2011, Alan Stern wrote:
> > On Mon, 31 Jan 2011, Kevin Hilman wrote:
> >
> > > I understand how this works, but frankly I'm still a bit fuzzy on why.
> > >
> > > I guess I'm still missing a good understanding of what "interfering with a
> > > system power transition" means, and why a runtime suspend qualifies as
> > > interfering but not a runtime resume.
> >
> > These are good questions. Rafael implemented this design originally;
> > my contribution was only to warn him of the potential for problems.
> > Therefore he should explain the rationale for the design.
>
> The reason why runtime resume is allowed during system power transitions is
> because in some cases during system suspend we simply have to resume devices
> that were previously runtime-suspended (for example, the PCI bus type does
> that).
>
> The reason why runtime suspend is not allowed during system power transitions
> if the following race:
>
> - A device has been suspended via a system suspend callback.
> - The runtime PM framework executes a (scheduled) suspend on that device,
> not knowing that it's already been suspended, which potentially results in
> accessing the device's registers in a low-power state.
>
> Now, it can be avoided if every driver does the right thing and checks whether
> the device is already suspended in its runtime suspend callback, but that would
> kind of defeat the purpose of the runtime PM framework, at least partially.
In fact, I've just realized that the above race cannot really occur, because
pm_wq is freezable, so I'm proposing the following change.
Of course, it still doesn't prevent user space from disabling the runtime PM
framework's helpers via /sys/devices/.../power/control.
Thanks,
Rafael
---
From: Rafael J. Wysocki <rjw@sisk.pl>
Subject: PM: Allow pm_runtime_suspend() to succeed during system suspend
The dpm_prepare() function increments the runtime PM reference
counters of all devices to prevent pm_runtime_suspend() from
executing subsystem-level callbacks. However, this was supposed to
guard against a specific race condition that cannot happen, because
the power management workqueue is freezable, so pm_runtime_suspend()
can only be called synchronously during system suspend and we can
rely on subsystems and device drivers to avoid doing that
unnecessarily.
Make dpm_prepare() drop the runtime PM reference to each device
after making sure that runtime resume is not pending for it.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
drivers/base/power/main.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
Index: linux-2.6/drivers/base/power/main.c
===================================================================
--- linux-2.6.orig/drivers/base/power/main.c
+++ linux-2.6/drivers/base/power/main.c
@@ -669,7 +669,6 @@ static void dpm_complete(pm_message_t st
mutex_unlock(&dpm_list_mtx);
device_complete(dev, state);
- pm_runtime_put_sync(dev);
mutex_lock(&dpm_list_mtx);
put_device(dev);
@@ -1005,12 +1004,9 @@ static int dpm_prepare(pm_message_t stat
if (pm_runtime_barrier(dev) && device_may_wakeup(dev))
pm_wakeup_event(dev, 0);
- if (pm_wakeup_pending()) {
- pm_runtime_put_sync(dev);
- error = -EBUSY;
- } else {
- error = device_prepare(dev, state);
- }
+ pm_runtime_put_sync(dev);
+ error = pm_wakeup_pending() ?
+ -EBUSY : device_prepare(dev, state);
mutex_lock(&dpm_list_mtx);
if (error) {
^ permalink raw reply
* [PATCH 2/2] OMAP2+: mailbox: fix lookups for multiple mailboxes
From: Kevin Hilman @ 2011-02-11 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297454203-28298-1-git-send-email-khilman@ti.com>
The pointer math in omap_mbox_get() is not quite right, and leads to
passing NULL to strcmp() when searching for an mbox that is not first
in the list.
Convert to using array indexing as is done in all the other functions
which walk the mbox list.
Tested on OMAP2420/n810, OMAP3630/zoom3, OMAP4430/Blaze
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
arch/arm/plat-omap/mailbox.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 459b319..49d3208 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -322,15 +322,18 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
struct omap_mbox *omap_mbox_get(const char *name, struct notifier_block *nb)
{
- struct omap_mbox *mbox;
- int ret;
+ struct omap_mbox *_mbox, *mbox = NULL;
+ int i, ret;
if (!mboxes)
return ERR_PTR(-EINVAL);
- for (mbox = *mboxes; mbox; mbox++)
- if (!strcmp(mbox->name, name))
+ for (i = 0; (_mbox = mboxes[i]); i++) {
+ if (!strcmp(_mbox->name, name)) {
+ mbox = _mbox;
break;
+ }
+ }
if (!mbox)
return ERR_PTR(-ENOENT);
--
1.7.4
^ permalink raw reply related
* [PATCH 1/2] OMAP2420: mailbox: fix IVA vs DSP IRQ numbering
From: Kevin Hilman @ 2011-02-11 19:56 UTC (permalink / raw)
To: linux-arm-kernel
The IRQ numbering for the IVA and DSP mailboxes was switched due
to the wrong ordering in the OMAP2 mbox list. Switch the ordering
so DSP is first and matches all the other SoCs.
Tested on OMAP2420/n810.
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/mailbox.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index b4cd2aa..1ccf1d6 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -334,7 +334,7 @@ static struct omap_mbox mbox_iva_info = {
.priv = &omap2_mbox_iva_priv,
};
-struct omap_mbox *omap2_mboxes[] = { &mbox_iva_info, &mbox_dsp_info, NULL };
+struct omap_mbox *omap2_mboxes[] = { &mbox_dsp_info, &mbox_iva_info, NULL };
#endif
#if defined(CONFIG_ARCH_OMAP4)
--
1.7.4
^ permalink raw reply related
* [RFC PATCH 3/3] ARM: vfp: Use cpu pm notifiers to save vfp state
From: Colin Cross @ 2011-02-11 19:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297426345.17584.99.camel@e102109-lin.cambridge.arm.com>
On Fri, Feb 11, 2011 at 4:12 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> Colin,
>
> On Thu, 2011-02-10 at 21:31 +0000, Colin Cross wrote:
>> +static int vfp_idle_notifier(struct notifier_block *self, unsigned long cmd,
>> + ? ? ? void *v)
>> +{
>> + ? ? ? u32 fpexc = fmrx(FPEXC);
>> + ? ? ? unsigned int cpu = smp_processor_id();
>> +
>> + ? ? ? if (cmd != CPU_PM_ENTER)
>> + ? ? ? ? ? ? ? return NOTIFY_OK;
>> +
>> + ? ? ? /* The VFP may be reset in idle, save the state */
>> + ? ? ? if ((fpexc & FPEXC_EN) && last_VFP_context[cpu]) {
>> + ? ? ? ? ? ? ? vfp_save_state(last_VFP_context[cpu], fpexc);
>> + ? ? ? ? ? ? ? last_VFP_context[cpu]->hard.cpu = cpu;
>> + ? ? ? }
>
> Should we only handle the case where the VFP is enabled? At context
> switch we disable the VFP and re-enable it when an application tries to
> use it but it will remain disabled even the application hasn't used the
> VFP. So switching to the idle thread would cause the VFP to be disabled
> but the state not necessarily saved.
Right
> On SMP systems, we save the VFP at every context switch to deal with the
> thread migration (though I have a plan to make this lazily on SMP as
> well). On UP however, we don't save the VFP registers at context switch,
> we just disable it and save it lazily if used later in a different task
>
> Something like below (untested):
>
> ? ? ? ?if (last_VFP_context[cpu]) {
> ? ? ? ? ? ? ? ?vfp_save_state(last_VFP_context[cpu], fpexc);
> ? ? ? ? ? ? ? ?/* force a reload when coming back from idle */
> ? ? ? ? ? ? ? ?last_VFP_context[cpu] = NULL;
> ? ? ? ? ? ? ? ?fmxr(FPEXC, fpexc & ~FPEXC_EN);
> ? ? ? ?}
>
> The last line (disabling) may not be necessary if we know that it comes
> back from idle as disabled.
It shouldn't be necessary, the context switch into the idle thread
should have disabled it, but it doesn't hurt. We should also disable
it when exiting idle.
> I wonder whether the current vfp_pm_suspend() function needs fixing for
> UP systems as well. It is find if the hardware preserves the VFP
> registers (which may not be the case).
I think there is a case where the VFP registers can be lost in suspend
on UP platforms that don't save the VFP registers in their platform
suspend. If a thread is using the VFP, and then context switches to a
thread that does not use VFP but triggers suspend by writing to
/sys/power/state, vfp_pm_suspend will be called with the VFP disabled
but the registers not saved. I think this would work:
/* save state for resumption */
if (last_VFP_context[ti->cpu]) {
printk(KERN_DEBUG "%s: saving vfp state\n", __func__);
vfp_save_state(last_VFP_context[ti->cpu], fpexc);
/* disable, just in case */
fmxr(FPEXC, fpexc & ~FPEXC_EN);
}
If the thread that wrote to /sys/power/state is using VFP,
last_VFP_context will be the same as ti->vfpstate, so we can always
save last_VFP_context.
^ permalink raw reply
* [PATCH v2 12/13] da850: pruss SUART platform specific additions.
From: Sergei Shtylyov @ 2011-02-11 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297435892-28278-13-git-send-email-subhasish@mistralsolutions.com>
Subhasish Ghosh wrote:
> This patch adds the McASP clock alias.
> The alias is used by the pruss suart driver
> for enabling the McASP PSC.
> Signed-off-by: Subhasish Ghosh <subhasish@mistralsolutions.com>
[...]
> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index e15de72..f1cf605 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -560,7 +560,18 @@ struct platform_device da8xx_pruss_dev = {
>
> int __init da8xx_register_pruss(struct da8xx_pruss_devices *pruss_device)
> {
> +#ifdef CONFIG_SERIAL_PRUSS_SUART_MODULE
#ifdef's in the function body are generally fromned upon.
> + int ret;
> +#endif
> +
This line should have been inside #ifdef...
> da8xx_pruss_dev.dev.platform_data = pruss_device;
> +
> +#ifdef CONFIG_SERIAL_PRUSS_SUART_MODULE
Why not do it before assigning the platform data and avoid extra #ifdef?
> + ret = clk_add_alias(NULL, "da8xx_pruss_uart.1",
> + NULL, &da850_mcasp_device.dev);
This line should be indented more to the right.
> + if (ret < 0)
> + return ret;
> +#endif
WBR, Sergei
^ permalink raw reply
* [PATCH v2 11/13] da850: pruss SUART board specific additions.
From: Sergei Shtylyov @ 2011-02-11 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297435892-28278-12-git-send-email-subhasish@mistralsolutions.com>
Subhasish Ghosh wrote:
> This patch adds the pruss SUART pin mux and registers the device
> with the pruss mfd driver.
> Signed-off-by: Subhasish Ghosh <subhasish@mistralsolutions.com>
> ---
> arch/arm/mach-davinci/board-da850-evm.c | 36 +++++++++++++++++++++++++++++++
> 1 files changed, 36 insertions(+), 0 deletions(-)
> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index f9c38f8..3858516 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
[...]
> @@ -1085,6 +1104,17 @@ static int __init da850_evm_setup_pruss_can(void)
> return ret;
> }
>
> +static struct da850_evm_pruss_suart_data suart_data = {
> + .version = 1,
> + .resource = {
> + .name = "da8xx_mcasp0_iomem",
> + .start = DAVINCI_DA8XX_MCASP0_REG_BASE,
> + .end = DAVINCI_DA8XX_MCASP0_REG_BASE +
> + (SZ_1K * 12) - 1,
> + .flags = IORESOURCE_MEM,
> + },
> +};
> +
I don't think passing a resource thru platform data is good idea...
Resources should be bound to the platform device.
WBR, Sergei
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox