Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Thu, 2011-01-27 at 18:59 +, Russell King - ARM Linux wrote: On Thu, Jan 27, 2011 at 06:14:56PM +, Catalin Marinas wrote: On 17 January 2011 19:24, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Rather than turning off CPU domain switching when the build architecture includes ARMv6K, thereby causing problems for ARMv6-supporting kernels, turn it on when it's required to support a CPU architecture. (sorry, I'm well behind list messages, didn't reply earlier) Does it mean that we get domains enabled even for ARMv7 when ARMv6 is built in the same kernel? The side effect is that user read-only addresses are writable by the kernel and SWP emulation no longer works. It means that a kernel with ARMv6 through to ARMv7 will have CPU domains enabled. So maybe we want: config CPU_32v6 select CPU_USE_DOMAINS if !CPU_V6K MMU instead? Does this mean that we could still configure a kernel to run on CPU_V6 with domains disabled? The vectors page becomes read-only and setting the TLS would fail. My point is that we may want SWP_EMULATE disabled (or depending on ! CPU_USE_DOMAINS). With domains enabled every read-only user page is writeable by the kernel. This has the side-effect that SWP emulation using LDREX/STREX breaks COW. We could change early_trap_init() to always use the vectors_page rather than the high mapping and determine at run-time (patch the code) whether set_pte_ext sets R/W kernel permissions for RO user pages. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, Jan 28, 2011 at 09:46:06AM +, Catalin Marinas wrote: Does this mean that we could still configure a kernel to run on CPU_V6 with domains disabled? The vectors page becomes read-only and setting the TLS would fail. Yes it will, so that's not acceptable either. My point is that we may want SWP_EMULATE disabled (or depending on ! CPU_USE_DOMAINS). With domains enabled every read-only user page is writeable by the kernel. This has the side-effect that SWP emulation using LDREX/STREX breaks COW. Yes, and maybe we should instead just enable the SWP instruction by default on ARMv7, and if SWP emulation is built, disable it at that point. We could change early_trap_init() to always use the vectors_page rather than the high mapping and determine at run-time (patch the code) whether set_pte_ext sets R/W kernel permissions for RO user pages. With aliasing caches that becomes much more difficult. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, 2011-01-28 at 09:59 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 09:46:06AM +, Catalin Marinas wrote: My point is that we may want SWP_EMULATE disabled (or depending on ! CPU_USE_DOMAINS). With domains enabled every read-only user page is writeable by the kernel. This has the side-effect that SWP emulation using LDREX/STREX breaks COW. Yes, and maybe we should instead just enable the SWP instruction by default on ARMv7, and if SWP emulation is built, disable it at that point. We can't disable the SWP instruction as long as domains are enabled (COW not working for in-kernel STREX). On ARMv7 we could always force R/O kernel/user pages in set_pte_ext independent of the domains setting and have early_trap_init() use vectors_page() if cpu_architecture() = 7 (this would actually catch ARM11MPCore as well because of the way we interpret CPUID). -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, Jan 28, 2011 at 10:46:51AM +, Catalin Marinas wrote: On Fri, 2011-01-28 at 09:59 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 09:46:06AM +, Catalin Marinas wrote: My point is that we may want SWP_EMULATE disabled (or depending on ! CPU_USE_DOMAINS). With domains enabled every read-only user page is writeable by the kernel. This has the side-effect that SWP emulation using LDREX/STREX breaks COW. Yes, and maybe we should instead just enable the SWP instruction by default on ARMv7, and if SWP emulation is built, disable it at that point. We can't disable the SWP instruction as long as domains are enabled (COW not working for in-kernel STREX). On ARMv7 we could always force R/O kernel/user pages in set_pte_ext independent of the domains setting and have early_trap_init() use vectors_page() if cpu_architecture() = 7 (this would actually catch ARM11MPCore as well because of the way we interpret CPUID). What about a kernel covering ARMv6 too? Writing to an aliased mapping of the vectors page (as required for TLS emulation) will require additional cache maintainence on every context switch. 1. SWP emulation requires domain support turned off 2. We can't turn domains off without creating a vectors page alias 3. We can't have a separate vectors alias with ARMv6 VIPT aliasing caches without additional cache maintainence. I don't think overloading the context switch with yet more conditionals based on yet more TLS combinations is a practical solution. So, ARMv6 TLS emulation, and SWP emulation are incompatible with each other. So either we don't have the SWP instruction at all on ARMv6+, or we have it enabled in hardware, or we don't and use the emulation where possible. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, 2011-01-28 at 11:06 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 10:46:51AM +, Catalin Marinas wrote: On Fri, 2011-01-28 at 09:59 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 09:46:06AM +, Catalin Marinas wrote: My point is that we may want SWP_EMULATE disabled (or depending on ! CPU_USE_DOMAINS). With domains enabled every read-only user page is writeable by the kernel. This has the side-effect that SWP emulation using LDREX/STREX breaks COW. Yes, and maybe we should instead just enable the SWP instruction by default on ARMv7, and if SWP emulation is built, disable it at that point. We can't disable the SWP instruction as long as domains are enabled (COW not working for in-kernel STREX). On ARMv7 we could always force R/O kernel/user pages in set_pte_ext independent of the domains setting and have early_trap_init() use vectors_page() if cpu_architecture() = 7 (this would actually catch ARM11MPCore as well because of the way we interpret CPUID). What about a kernel covering ARMv6 too? Writing to an aliased mapping of the vectors page (as required for TLS emulation) will require additional cache maintainence on every context switch. With your latest patches, do we use the TLS emulation on ARMv7 (UP) if v6 is compiled in? If that's the case, we may have a problem - I talked to the toolchain guys and it looks like code optimised for ARMv7 reads the TLS register directly without going through the kuser helper. So you may have people taking an Ubuntu filesystem (v7 only) and a pre-built OMAP image with TLS emulation even on Cortex-A8 and things won't work as expected. On ARMv6 with domains enabled, cpu_v6_set_pte_ext() maps the vectors page as kernel R/W. The cpu_v7_set_pte_ext() could map it as kernel RO and use the TLS register. The only other place where this matters on ARMv7 is early_trap_init() but it's easily fixable on this architecture. 1. SWP emulation requires domain support turned off Not necessarily - it requires RO user pages to be kernel RO (though this feature came with the domains removal patch). 2. We can't turn domains off without creating a vectors page alias Correct. 3. We can't have a separate vectors alias with ARMv6 VIPT aliasing caches without additional cache maintainence. Correct. I don't think overloading the context switch with yet more conditionals based on yet more TLS combinations is a practical solution. Yet another run-time code patching for the TLS, though it gets a bit complex. But we may need to solve it for the v7 filesystem case I mentioned above. So, ARMv6 TLS emulation, and SWP emulation are incompatible with each other. Yes. So either we don't have the SWP instruction at all on ARMv6+, or we have it enabled in hardware, or we don't and use the emulation where possible. If we can't sort out TLS register setting on v6+v7 kernels (I think we should), then we must have the SWP instruction enabled (no emulation). Which gets us back to the SWP_EMULATE depend on (CPU_V7 !CPU_V6). -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, Jan 28, 2011 at 12:25:18PM +, Catalin Marinas wrote: On Fri, 2011-01-28 at 11:06 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 10:46:51AM +, Catalin Marinas wrote: On Fri, 2011-01-28 at 09:59 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 09:46:06AM +, Catalin Marinas wrote: My point is that we may want SWP_EMULATE disabled (or depending on ! CPU_USE_DOMAINS). With domains enabled every read-only user page is writeable by the kernel. This has the side-effect that SWP emulation using LDREX/STREX breaks COW. Yes, and maybe we should instead just enable the SWP instruction by default on ARMv7, and if SWP emulation is built, disable it at that point. We can't disable the SWP instruction as long as domains are enabled (COW not working for in-kernel STREX). On ARMv7 we could always force R/O kernel/user pages in set_pte_ext independent of the domains setting and have early_trap_init() use vectors_page() if cpu_architecture() = 7 (this would actually catch ARM11MPCore as well because of the way we interpret CPUID). What about a kernel covering ARMv6 too? Writing to an aliased mapping of the vectors page (as required for TLS emulation) will require additional cache maintainence on every context switch. With your latest patches, do we use the TLS emulation on ARMv7 (UP) if v6 is compiled in? If that's the case, we may have a problem - I talked to the toolchain guys and it looks like code optimised for ARMv7 reads the TLS register directly without going through the kuser helper. That's not a problem, because you wouldn't run ARMv7 optimized userspace on an ARMv6 CPU. That's not what this whole exercise is about. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, 2011-01-28 at 13:05 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 12:25:18PM +, Catalin Marinas wrote: With your latest patches, do we use the TLS emulation on ARMv7 (UP) if v6 is compiled in? If that's the case, we may have a problem - I talked to the toolchain guys and it looks like code optimised for ARMv7 reads the TLS register directly without going through the kuser helper. That's not a problem, because you wouldn't run ARMv7 optimized userspace on an ARMv6 CPU. That's not what this whole exercise is about. But you can run ARMv7 optimised userspace on ARMv7 CPU with a kernel image compiled for v6+v7. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, Jan 28, 2011 at 12:25:18PM +, Catalin Marinas wrote: On Fri, 2011-01-28 at 11:06 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 10:46:51AM +, Catalin Marinas wrote: On Fri, 2011-01-28 at 09:59 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 09:46:06AM +, Catalin Marinas wrote: My point is that we may want SWP_EMULATE disabled (or depending on ! CPU_USE_DOMAINS). With domains enabled every read-only user page is writeable by the kernel. This has the side-effect that SWP emulation using LDREX/STREX breaks COW. Yes, and maybe we should instead just enable the SWP instruction by default on ARMv7, and if SWP emulation is built, disable it at that point. We can't disable the SWP instruction as long as domains are enabled (COW not working for in-kernel STREX). On ARMv7 we could always force R/O kernel/user pages in set_pte_ext independent of the domains setting and have early_trap_init() use vectors_page() if cpu_architecture() = 7 (this would actually catch ARM11MPCore as well because of the way we interpret CPUID). What about a kernel covering ARMv6 too? Writing to an aliased mapping of the vectors page (as required for TLS emulation) will require additional cache maintainence on every context switch. With your latest patches, do we use the TLS emulation on ARMv7 (UP) if v6 is compiled in? If that's the case, we may have a problem - I talked to the toolchain guys and it looks like code optimised for ARMv7 reads the TLS register directly without going through the kuser helper. So you may have people taking an Ubuntu filesystem (v7 only) and a pre-built OMAP image with TLS emulation even on Cortex-A8 and things won't work as expected. You're really making a mountain out of TLS. If we have a v6+v6k+v7 kernel, then the way the kernel TLS code is built, we will use the TLS register if that's available on the hardware. If it isn't, we will write the TLS value directly to virtual 0x0ffc. So, a kernel built for v6+v6k+v7, when run on v7, will set the hardware TLS register, and your v7 optimized binaries which access the TLS register directly will work. Same for v6k. For v6, you won't be able to run v7 optimized binaries on that hardware anyway, because it doesn't have the TLS register, and as such the instructions which access it will fault. That's true whether you have a v6 only kernel or a v6+v6k+v7 kernel. What we're discussing has nothing at all to do with getting v7 binaries running on v6 hardware. That's just not going to happen. On ARMv6 with domains enabled, cpu_v6_set_pte_ext() maps the vectors page as kernel R/W. The cpu_v7_set_pte_ext() could map it as kernel RO and use the TLS register. The only other place where this matters on ARMv7 is early_trap_init() but it's easily fixable on this architecture. That's pointless. There's no could map the vectors page - set_pte_ext() doesn't know what's the vectors page and what isn't. It's about how set_pte_ext() maps pages which are marked with just L_PTE_USER. All L_PTE_USER pages get mapped as user read-only. Whether they get mapped SVC read-only or SVC read-write depends on whether we support domains. Without domains, they're mapped SVC read-write, and we need to use the ldrt/strt instructions. With domains, they're mapped SVC read-only, and we no longer need the ldrt/strt instructions. 1. SWP emulation requires domain support turned off Not necessarily - it requires RO user pages to be kernel RO (though this feature came with the domains removal patch). Yes it does because without domains, we need user pages to be kernel read-only, which also makes the vectors page kernel read-only. 2. We can't turn domains off without creating a vectors page alias Correct. 3. We can't have a separate vectors alias with ARMv6 VIPT aliasing caches without additional cache maintainence. Correct. I don't think overloading the context switch with yet more conditionals based on yet more TLS combinations is a practical solution. Yet another run-time code patching for the TLS, though it gets a bit complex. It _already_ is complex. We don't need any more complexity there. Have a look in asm/tls.h to see that there's already four different cases we have to consider. But we may need to solve it for the v7 filesystem case I mentioned above. No we don't. We're already selecting the code appropriately from four different cases for the supported processor types. We don't need maybe the vectors page is read-only introducing another two cases with complex cache flushing and location of the vectors page, and we certainly don't need this complication at runtime. If we can't sort out TLS register setting on v6+v7 kernels (I think we should), then we must have the SWP instruction enabled (no emulation). Which gets us back to the SWP_EMULATE depend on (CPU_V7 !CPU_V6). That I think is the
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, Jan 28, 2011 at 01:10:56PM +, Catalin Marinas wrote: On Fri, 2011-01-28 at 13:05 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 12:25:18PM +, Catalin Marinas wrote: With your latest patches, do we use the TLS emulation on ARMv7 (UP) if v6 is compiled in? If that's the case, we may have a problem - I talked to the toolchain guys and it looks like code optimised for ARMv7 reads the TLS register directly without going through the kuser helper. That's not a problem, because you wouldn't run ARMv7 optimized userspace on an ARMv6 CPU. That's not what this whole exercise is about. But you can run ARMv7 optimised userspace on ARMv7 CPU with a kernel image compiled for v6+v7. Yes. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Fri, 2011-01-28 at 13:21 +, Russell King - ARM Linux wrote:
On Fri, Jan 28, 2011 at 12:25:18PM +, Catalin Marinas wrote:
With your latest patches, do we use the TLS emulation on ARMv7 (UP) if
v6 is compiled in? If that's the case, we may have a problem - I talked
to the toolchain guys and it looks like code optimised for ARMv7 reads
the TLS register directly without going through the kuser helper. So you
may have people taking an Ubuntu filesystem (v7 only) and a pre-built
OMAP image with TLS emulation even on Cortex-A8 and things won't work as
expected.
You're really making a mountain out of TLS.
Not really, just asking for clarification as I haven't checked all your
patches recently.
If we have a v6+v6k+v7 kernel, then the way the kernel TLS code is built,
we will use the TLS register if that's available on the hardware. If it
isn't, we will write the TLS value directly to virtual 0x0ffc.
So, a kernel built for v6+v6k+v7, when run on v7, will set the hardware
TLS register, and your v7 optimized binaries which access the TLS register
directly will work. Same for v6k.
Great.
What we're discussing has nothing at all to do with getting v7 binaries
running on v6 hardware. That's just not going to happen.
I wasn't suggesting this. That's not easily possible.
On ARMv6 with domains enabled, cpu_v6_set_pte_ext() maps the vectors
page as kernel R/W. The cpu_v7_set_pte_ext() could map it as kernel RO
and use the TLS register. The only other place where this matters on
ARMv7 is early_trap_init() but it's easily fixable on this architecture.
That's pointless. There's no could map the vectors page - set_pte_ext()
doesn't know what's the vectors page and what isn't. It's about how
set_pte_ext() maps pages which are marked with just L_PTE_USER.
What I meant is that we leave cpu_v6_set_pte_ext as it is (with R/W
kernel access for RO user pages) and always mark such pages kernel RO in
cpu_v7_set_pte_ext. See patch at the end of this email.
1. SWP emulation requires domain support turned off
Not necessarily - it requires RO user pages to be kernel RO (though this
feature came with the domains removal patch).
Yes it does because without domains, we need user pages to be kernel
read-only, which also makes the vectors page kernel read-only.
But even with domains we can make user pages kernel RO for ARMv7 only.
The only use which SWP_EMULATE gets us then is detecting userspace
programs which use the SWP instruction - and that can only happen on
a V7-only or v6k+v7 targetted kernel.
In some MP hardware configurations, SWP may not ensure atomicity across
all the CPUs. Exclusives would ensure this behaviour.
The patch below allows domains to be enabled on ARMv7 and also use SWP
emulation (tested on VE + A9 with domains enabled):
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 0x, 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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
* Catalin Marinas catalin.mari...@arm.com [110128 07:11]: On Fri, 2011-01-28 at 13:21 +, Russell King - ARM Linux wrote: On Fri, Jan 28, 2011 at 12:25:18PM +, Catalin Marinas wrote: With your latest patches, do we use the TLS emulation on ARMv7 (UP) if v6 is compiled in? If that's the case, we may have a problem - I talked to the toolchain guys and it looks like code optimised for ARMv7 reads the TLS register directly without going through the kuser helper. So you may have people taking an Ubuntu filesystem (v7 only) and a pre-built OMAP image with TLS emulation even on Cortex-A8 and things won't work as expected. You're really making a mountain out of TLS. Not really, just asking for clarification as I haven't checked all your patches recently. If we have a v6+v6k+v7 kernel, then the way the kernel TLS code is built, we will use the TLS register if that's available on the hardware. If it isn't, we will write the TLS value directly to virtual 0x0ffc. So, a kernel built for v6+v6k+v7, when run on v7, will set the hardware TLS register, and your v7 optimized binaries which access the TLS register directly will work. Same for v6k. Great. Yes AFAIK we sorted out the TLS issue already a while back for v6+v6k+v7. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On 17 January 2011 19:24, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Rather than turning off CPU domain switching when the build architecture includes ARMv6K, thereby causing problems for ARMv6-supporting kernels, turn it on when it's required to support a CPU architecture. (sorry, I'm well behind list messages, didn't reply earlier) Does it mean that we get domains enabled even for ARMv7 when ARMv6 is built in the same kernel? The side effect is that user read-only addresses are writable by the kernel and SWP emulation no longer works. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Thu, Jan 27, 2011 at 06:14:56PM +, Catalin Marinas wrote: On 17 January 2011 19:24, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Rather than turning off CPU domain switching when the build architecture includes ARMv6K, thereby causing problems for ARMv6-supporting kernels, turn it on when it's required to support a CPU architecture. (sorry, I'm well behind list messages, didn't reply earlier) Does it mean that we get domains enabled even for ARMv7 when ARMv6 is built in the same kernel? The side effect is that user read-only addresses are writable by the kernel and SWP emulation no longer works. It means that a kernel with ARMv6 through to ARMv7 will have CPU domains enabled. So maybe we want: config CPU_32v6 select CPU_USE_DOMAINS if !CPU_V6K MMU instead? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
On Mon, 17 Jan 2011, Russell King - ARM Linux wrote: Rather than turning off CPU domain switching when the build architecture includes ARMv6K, thereby causing problems for ARMv6-supporting kernels, turn it on when it's required to support a CPU architecture. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Nicolas Pitre nicolas.pi...@linaro.org --- arch/arm/mm/Kconfig |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index 22a3f4a..29215f5 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -435,25 +435,30 @@ config CPU_32v3 bool select TLS_REG_EMUL if SMP || !MMU select NEEDS_SYSCALL_FOR_CMPXCHG if SMP + select CPU_USE_DOMAINS if MMU config CPU_32v4 bool select TLS_REG_EMUL if SMP || !MMU select NEEDS_SYSCALL_FOR_CMPXCHG if SMP + select CPU_USE_DOMAINS if MMU config CPU_32v4T bool select TLS_REG_EMUL if SMP || !MMU select NEEDS_SYSCALL_FOR_CMPXCHG if SMP + select CPU_USE_DOMAINS if MMU config CPU_32v5 bool select TLS_REG_EMUL if SMP || !MMU select NEEDS_SYSCALL_FOR_CMPXCHG if SMP + select CPU_USE_DOMAINS if MMU config CPU_32v6 bool select TLS_REG_EMUL if !CPU_32v6K !MMU + select CPU_USE_DOMAINS if CPU_V6 MMU config CPU_32v6K bool Support ARM V6K processor extensions if !SMP @@ -620,8 +625,6 @@ config CPU_CP15_MPU config CPU_USE_DOMAINS bool - depends on MMU - default y if !CPU_32v6K help This option enables or disables the use of domain switching via the set_fs() function. -- 1.6.2.5 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: v6k: use CPU domain feature if we include support for arch ARMv6K
* Nicolas Pitre n...@fluxnic.net [110117 14:02]: On Mon, 17 Jan 2011, Russell King - ARM Linux wrote: Rather than turning off CPU domain switching when the build architecture includes ARMv6K, thereby causing problems for ARMv6-supporting kernels, turn it on when it's required to support a CPU architecture. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Nicolas Pitre nicolas.pi...@linaro.org Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
