* [RFC v3 PATCH 08/25] ARM: NOMMU: fix head-nommu build for pre-ARMv7 CPUs
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
While building for pre-ARMv7 CPUs with ARM_MPU enabled following error
shows up:
AS arch/arm/kernel/head-nommu.o
arch/arm/kernel/head-nommu.S: Assembler messages:
arch/arm/kernel/head-nommu.S:223: Error: selected processor does not support ARM mode `isb'
arch/arm/kernel/head-nommu.S:231: Error: selected processor does not support ARM mode `isb'
arch/arm/kernel/head-nommu.S:235: Error: selected processor does not support ARM mode `isb'
arch/arm/kernel/head-nommu.S:244: Error: selected processor does not support ARM mode `isb'
arch/arm/kernel/head-nommu.S:248: Error: selected processor does not support ARM mode `isb'
arch/arm/kernel/head-nommu.S:258: Error: selected processor does not support ARM mode `isb'
arch/arm/kernel/head-nommu.S:265: Error: selected processor does not support ARM mode `isb'
make[1]: *** [arch/arm/kernel/head-nommu.o] Error 1
MPU setup code is available for ARMv7 only, but head-nommu.S is
generic, so build head-nommu.S with -march=armv7-a (and armv7-m for
M-calss to avoid "Conflicting architecture profiles M/A" link time)
flag; in case pre-ARMv7 it detects there there is no MPU is avaliable,
so it will never reach those instructions.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/kernel/Makefile | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index ad325a8..6da8b04 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -84,6 +84,11 @@ endif
obj-$(CONFIG_PARAVIRT) += paravirt.o
head-y := head$(MMUEXT).o
+ifeq ($(CONFIG_CPU_V7M),y)
+AFLAGS_head-nommu.o :=-Wa,-march=armv7-m
+else
+AFLAGS_head-nommu.o :=-Wa,-march=armv7-a
+endif
obj-$(CONFIG_DEBUG_LL) += debug.o
obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 09/25] ARM: NOMMU: fix load of CONFIG_VECTORS_BASE
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
While running randconfig with NOMMU enabled following error shows up:
arch/arm/kernel/head-nommu.S: Assembler messages:
arch/arm/kernel/head-nommu.S:265: Error: invalid constant (ffffffffffff0000) after fixup
make[1]: *** [arch/arm/kernel/head-nommu.o] Error 1
That happens because CONFIG_VECTORS_BASE it is out of range of the mov
instruction. So use ldr pseudo instruction instead and let assembler
to figure out how to deal with that.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/kernel/head-nommu.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index 7317554..ae80c71 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -251,7 +251,7 @@ ENTRY(__setup_mpu)
set_region_nr r0, #MPU_VECTORS_REGION
isb
/* Shared, inaccessible to PL0, rw PL1 */
- mov r0, #CONFIG_VECTORS_BASE @ Cover from VECTORS_BASE
+ ldr r0, =CONFIG_VECTORS_BASE @ Cover from VECTORS_BASE
ldr r5,=(MPU_AP_PL1RW_PL0NA | MPU_RGN_NORMAL)
/* Writing N to bits 5:1 (RSR_SZ) --> region size 2^N+1 */
mov r6, #(((2 * PAGE_SHIFT - 1) << MPU_RSR_SZ) | 1 << MPU_RSR_EN)
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 10/25] ARM: NOMMU: implement secondary_startup_arm
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
Mediatek's and Qualcomm's platform code has reference to
secondary_startup_arm and that breaks NOMMU build.
Since head-nommu.S is common, we need to take extra care of M-class
platforms since there are no ARM instructions avaliable there. Even
though secondary_startup_arm is build it in SMP configuration only
(which is not supported by M-class) it'd be better to be on the safe
side and handle Thumb-only case there - keep in Thumb mode and fall
through to secondary_startup.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/kernel/head-nommu.S | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index ae80c71..f5bb554 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -88,7 +88,17 @@ ENTRY(stext)
ENDPROC(stext)
#ifdef CONFIG_SMP
- .text
+#ifdef CONFIG_CPU_THUMBONLY
+ .thumb
+ENTRY(secondary_startup_arm)
+#else
+ .arm
+ENTRY(secondary_startup_arm)
+ THUMB( badr r9, 1f ) @ Kernel is entered in ARM.
+ THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
+ THUMB( .thumb ) @ switch to Thumb now.
+ THUMB(1: )
+#endif
ENTRY(secondary_startup)
/*
* Common entry point for secondary CPUs.
@@ -126,6 +136,7 @@ ENTRY(secondary_startup)
mov fp, #0
b secondary_start_kernel
ENDPROC(secondary_startup)
+ENDPROC(secondary_startup_arm)
.type __secondary_data, %object
__secondary_data:
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 11/25] ARM: move arm_heavy_mb to MMU/noMMU neutral place
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
So it can be referenced from both camps.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/mm/flush.c | 15 ---------------
arch/arm/mm/iomap.c | 17 +++++++++++++++++
2 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
index 3cced84..0c73969 100644
--- a/arch/arm/mm/flush.c
+++ b/arch/arm/mm/flush.c
@@ -21,21 +21,6 @@
#include "mm.h"
-#ifdef CONFIG_ARM_HEAVY_MB
-void (*soc_mb)(void);
-
-void arm_heavy_mb(void)
-{
-#ifdef CONFIG_OUTER_CACHE_SYNC
- if (outer_cache.sync)
- outer_cache.sync();
-#endif
- if (soc_mb)
- soc_mb();
-}
-EXPORT_SYMBOL(arm_heavy_mb);
-#endif
-
#ifdef CONFIG_CPU_CACHE_VIPT
static void flush_pfn_alias(unsigned long pfn, unsigned long vaddr)
diff --git a/arch/arm/mm/iomap.c b/arch/arm/mm/iomap.c
index 4614208..1b601db 100644
--- a/arch/arm/mm/iomap.c
+++ b/arch/arm/mm/iomap.c
@@ -9,6 +9,8 @@
#include <linux/ioport.h>
#include <linux/io.h>
+#include <asm/outercache.h>
+
unsigned long vga_base;
EXPORT_SYMBOL(vga_base);
@@ -40,3 +42,18 @@ void pci_iounmap(struct pci_dev *dev, void __iomem *addr)
}
EXPORT_SYMBOL(pci_iounmap);
#endif
+
+#ifdef CONFIG_ARM_HEAVY_MB
+void (*soc_mb)(void);
+
+void arm_heavy_mb(void)
+{
+#ifdef CONFIG_OUTER_CACHE_SYNC
+ if (outer_cache.sync)
+ outer_cache.sync();
+#endif
+ if (soc_mb)
+ soc_mb();
+}
+EXPORT_SYMBOL(arm_heavy_mb);
+#endif
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 12/25] ARM: tlbflush: drop dependency on CONFIG_SMP
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
While building NOMMU and UP following errors show up:
arch/arm/mach-mvebu/pmsu.c: In function 'armada_370_xp_pmsu_idle_enter':
arch/arm/mach-mvebu/pmsu.c:291:2: error: implicit declaration of function 'local_flush_tlb_all' [-Werror=implicit-function-declaration]
local_flush_tlb_all();
^
CC arch/arm/mach-omap2/control.o
cc1: some warnings being treated as errors
make[1]: *** [arch/arm/mach-mvebu/pmsu.o] Error 1
...
arch/arm/mach-imx/pm-imx5.c: In function 'mx5_suspend_enter':
arch/arm/mach-imx/pm-imx5.c:227:3: error: implicit declaration of function 'local_flush_tlb_all' [-Werror=implicit-function-declaration]
local_flush_tlb_all();
^
cc1: some warnings being treated as errors
make[1]: *** [arch/arm/mach-imx/pm-imx5.o] Error 1
...
arch/arm/mach-imx/pm-imx6.c: In function 'imx6q_suspend_finish':
arch/arm/mach-imx/pm-imx6.c:354:3: error: implicit declaration of function 'local_flush_tlb_all' [-Werror=implicit-function-declaration]
local_flush_tlb_all();
^
cc1: some warnings being treated as errors
make[1]: *** [arch/arm/mach-imx/pm-imx6.o] Error 1
Make local_* stuff available for UP (even though it doesn't make
sense) so build can progress.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/include/asm/tlbflush.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index def9e57..d9a6e2e 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -641,7 +641,7 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
#endif
-#elif defined(CONFIG_SMP) /* !CONFIG_MMU */
+#else /* !CONFIG_MMU */
#ifndef __ASSEMBLY__
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 13/25] ARM: sleep: allow it to be build for R-class
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
cpu_resume_arm was guarded with CONFIG_MMU in 2678bb9fa13 (ARM: fix
EFM32 build breakage caused by cpu_resume_arm) in response to broken
build for EFM32 platform which has M-class cpu. It turned out that
this dependency on MMU is quite strict and prevent R-class from being
built.
The root cause of build breakage for M-class is that there is no ARM
instructions supported there. So instead of limiting cpu_resume_arm to
MMU only build, lets handle M-class case properly - keep in Thumb mode
and fall through to cpu_resume.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/kernel/sleep.S | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index 0f6c100..41b512d 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -119,7 +119,10 @@ ENDPROC(cpu_resume_after_mmu)
.text
.align
-#ifdef CONFIG_MMU
+#ifdef CONFIG_CPU_THUMBONLY
+ .thumb
+ENTRY(cpu_resume_arm)
+#else
.arm
ENTRY(cpu_resume_arm)
THUMB( badr r9, 1f ) @ Kernel is entered in ARM.
@@ -159,10 +162,7 @@ THUMB( ldmia r0!, {r1, r2, r3} )
THUMB( mov sp, r2 )
THUMB( bx r3 )
ENDPROC(cpu_resume)
-
-#ifdef CONFIG_MMU
ENDPROC(cpu_resume_arm)
-#endif
.align 2
_sleep_save_sp:
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 14/25] ARM: setup: move call to erratum_a15_798181_init under CONFIG_MMU
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
While building for NOMMU link time error shows up:
arch/arm/kernel/built-in.o: In function `setup_arch':
arch/arm/kernel/smccc-call.o:(.init.text+0xa50): undefined reference to `erratum_a15_798181_init'
It happens because erratum_a15_798181_init() lives under smp_tlb.c
which is build only for MMU configurations. So do call this function
only if build with CONFIG_MMU.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/kernel/setup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 34e3f3c..2254396 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -717,9 +717,9 @@ static void __init setup_processor(void)
#endif
#ifdef CONFIG_MMU
init_default_cache_policy(list->__cpu_mm_mmu_flags);
-#endif
- erratum_a15_798181_init();
+ erratum_a15_798181_init();
+#endif
elf_hwcap_fixup();
cacheid_init();
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 15/25] ARM: kexec: disallow kexec for NOMMU builds
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
While building for NOMMU the following error shows up:
kernel/built-in.o: In function `kimage_free_entry':
memremap.c:(.text+0x4dafc): undefined reference to `arch_phys_to_idmap_offset'
memremap.c:(.text+0x4db04): undefined reference to `arch_phys_to_idmap_offset'
kernel/built-in.o: In function `kimage_alloc_page':
memremap.c:(.text+0x4dbc0): undefined reference to `arch_phys_to_idmap_offset'
memremap.c:(.text+0x4dbc8): undefined reference to `arch_phys_to_idmap_offset'
memremap.c:(.text+0x4dc1c): undefined reference to `arch_phys_to_idmap_offset'
That comes from Kexec, add dependency on MMU there.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529f..90c91de 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2019,7 +2019,7 @@ config XIP_PHYS_ADDR
config KEXEC
bool "Kexec system call (EXPERIMENTAL)"
depends on (!SMP || PM_SLEEP_SMP)
- depends on !CPU_V7M
+ depends on MMU
select KEXEC_CORE
help
kexec is a system call that implements the ability to shutdown your
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 16/25] ARM: ep93xx: select ARM_PATCH_PHYS_VIRT for MMU builds only
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
Building in NOMMU configurations lead to the following splat:
warning: (ARCH_INTEGRATOR && ARCH_MULTIPLATFORM && ARCH_EP93XX) selects ARM_PATCH_PHYS_VIRT which has unmet direct dependencies (!XIP_KERNEL && MMU)
Make sure ARM_PATCH_PHYS_VIRT is selected for MMU builds only.
Cc: Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ryan Mallon <rmallon@gmail.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 90c91de..b3fa6e9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -380,7 +380,7 @@ config ARCH_EP93XX
bool "EP93xx-based"
select ARCH_HAS_HOLES_MEMORYMODEL
select ARM_AMBA
- select ARM_PATCH_PHYS_VIRT
+ select ARM_PATCH_PHYS_VIRT if MMU
select ARM_VIC
select AUTO_ZRELADDR
select CLKDEV_LOOKUP
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 17/25] ARM: omap: do not select HIGHMEM explicitly
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
Explicit selection of HIGHMEM breaks NOMMU builds. It seems that
HIGHMEM is user selectable option, so probably it would be better to
let user to make a decision on this options or, at least, move it to
defconfig.
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0465338..daddddc 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -121,7 +121,6 @@ config ARCH_OMAP2PLUS_TYPICAL
bool "Typical OMAP configuration"
default y
select AEABI
- select HIGHMEM
select I2C
select I2C_OMAP
select MENELAUS if ARCH_OMAP2
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 18/25] ARM: sa1100: move CPU specific copy code under its own config
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
By now there is no way to limit sa1100 specific copy code to MMU only
builds and that leads to the following error when built for NOMMU
arch/arm/mm/copypage-v4mc.c:26:35: error: 'L_PTE_PRESENT' undeclared (first use in this function)
#define minicache_pgprot __pgprot(L_PTE_PRESENT | L_PTE_YOUNG | \
^
./arch/arm/include/asm/page-nommu.h:41:26: note: in definition of macro '__pgprot'
#define __pgprot(x) (x)
^
arch/arm/mm/copypage-v4mc.c:77:47: note: in expansion of macro 'minicache_pgprot'
set_top_pte(COPYPAGE_MINICACHE, mk_pte(from, minicache_pgprot));
^
arch/arm/mm/copypage-v4mc.c:26:51: error: 'L_PTE_YOUNG' undeclared (first use in this function)
#define minicache_pgprot __pgprot(L_PTE_PRESENT | L_PTE_YOUNG | \
^
./arch/arm/include/asm/page-nommu.h:41:26: note: in definition of macro '__pgprot'
#define __pgprot(x) (x)
^
arch/arm/mm/copypage-v4mc.c:77:47: note: in expansion of macro 'minicache_pgprot'
set_top_pte(COPYPAGE_MINICACHE, mk_pte(from, minicache_pgprot));
^
arch/arm/mm/copypage-v4mc.c:27:7: error: 'L_PTE_MT_MINICACHE' undeclared (first use in this function)
L_PTE_MT_MINICACHE)
^
./arch/arm/include/asm/page-nommu.h:41:26: note: in definition of macro '__pgprot'
#define __pgprot(x) (x)
^
arch/arm/mm/copypage-v4mc.c:77:47: note: in expansion of macro 'minicache_pgprot'
set_top_pte(COPYPAGE_MINICACHE, mk_pte(from, minicache_pgprot));
^
arch/arm/mm/copypage-v4mc.c: At top level:
arch/arm/mm/copypage-v4mc.c:112:8: error: variable 'v4_mc_user_fns' has initializer but incomplete type
struct cpu_user_fns v4_mc_user_fns __initdata = {
^
arch/arm/mm/copypage-v4mc.c:113:2: error: unknown field 'cpu_clear_user_highpage' specified in initializer
.cpu_clear_user_highpage = v4_mc_clear_user_highpage,
^
arch/arm/mm/copypage-v4mc.c:113:2: warning: excess elements in struct initializer
arch/arm/mm/copypage-v4mc.c:113:2: warning: (near initialization for 'v4_mc_user_fns')
arch/arm/mm/copypage-v4mc.c:114:2: error: unknown field 'cpu_copy_user_highpage' specified in initializer
.cpu_copy_user_highpage = v4_mc_copy_user_highpage,
^
arch/arm/mm/copypage-v4mc.c:114:2: warning: excess elements in struct initializer
arch/arm/mm/copypage-v4mc.c:114:2: warning: (near initialization for 'v4_mc_user_fns')
cc1: some warnings being treated as errors
make[1]: *** [arch/arm/mm/copypage-v4mc.o] Error 1
make: *** [arch/arm/mm] Error 2
Move that code under CPU_COPY_V4MC config option which we can guard
against NOMMU configuration.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/include/asm/page.h | 2 +-
arch/arm/mm/Kconfig | 4 ++++
arch/arm/mm/Makefile | 2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/page.h b/arch/arm/include/asm/page.h
index 4355f0e..6ec7bb6 100644
--- a/arch/arm/include/asm/page.h
+++ b/arch/arm/include/asm/page.h
@@ -75,7 +75,7 @@
# endif
#endif
-#ifdef CONFIG_CPU_SA1100
+#ifdef CONFIG_CPU_COPY_V4MC
# ifdef _USER
# define MULTI_USER 1
# else
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index c1799dd..6dffbe4 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -290,6 +290,7 @@ config CPU_SA1100
select CPU_ABRT_EV4
select CPU_CACHE_V4WB
select CPU_CACHE_VIVT
+ select CPU_COPY_V4MC if MMU
select CPU_CP15_MMU
select CPU_PABRT_LEGACY
select CPU_TLB_V4WB if MMU
@@ -524,6 +525,9 @@ config CPU_CACHE_V7M
if MMU
# The copy-page model
+config CPU_COPY_V4MC
+ bool
+
config CPU_COPY_V4WT
bool
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index e869824..2ac7988 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -53,7 +53,7 @@ obj-$(CONFIG_CPU_COPY_V4WT) += copypage-v4wt.o
obj-$(CONFIG_CPU_COPY_V4WB) += copypage-v4wb.o
obj-$(CONFIG_CPU_COPY_FEROCEON) += copypage-feroceon.o
obj-$(CONFIG_CPU_COPY_V6) += copypage-v6.o context.o
-obj-$(CONFIG_CPU_SA1100) += copypage-v4mc.o
+obj-$(CONFIG_CPU_COPY_V4MC) += copypage-v4mc.o
obj-$(CONFIG_CPU_XSCALE) += copypage-xscale.o
obj-$(CONFIG_CPU_XSC3) += copypage-xsc3.o
obj-$(CONFIG_CPU_COPY_FA) += copypage-fa.o
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 19/25] ARM: sa11x0: assabet: add dependency on MMU
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
Building for NOMMU configuration leads to following error:
arch/arm/mach-sa1100/generic.c:350:24: warning: 'standard_io_desc' defined but not used [-Wunused-variable]
static struct map_desc standard_io_desc[] __initdata = {
^
arch/arm/mach-sa1100/assabet.c: In function 'map_sa1100_gpio_regs':
arch/arm/mach-sa1100/assabet.c:496:38: error: 'PMD_MASK' undeclared (first use in this function)
unsigned long phys = __PREG(GPLR) & PMD_MASK;
^
arch/arm/mach-sa1100/assabet.c:496:38: note: each undeclared identifier is reported only once for each function it appears in
In file included from ./include/linux/list.h:7:0,
from ./include/linux/module.h:9,
from arch/arm/mach-sa1100/assabet.c:14:
./arch/arm/include/asm/pgtable-2level-hwdef.h:22:29: error: 'pmdval_t' undeclared (first use in this function)
#define PMD_TYPE_SECT (_AT(pmdval_t, 2) << 0)
^
./include/uapi/linux/const.h:21:20: note: in definition of macro '_AT'
#define _AT(T,X) ((T)(X))
^
arch/arm/mach-sa1100/assabet.c:498:13: note: in expansion of macro 'PMD_TYPE_SECT'
int prot = PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_DOMAIN(DOMAIN_IO);
^
arch/arm/mach-sa1100/assabet.c:503:2: error: implicit declaration of function 'flush_pmd_entry' [-Werror=implicit-function-declaration]
flush_pmd_entry(pmd);
^
arch/arm/mach-sa1100/assabet.c:497:16: warning: unused variable 'virt' [-Wunused-variable]
unsigned long virt = (unsigned long)io_p2v(phys);
^
arch/arm/mach-sa1100/assabet.c: At top level:
arch/arm/mach-sa1100/assabet.c:620:24: warning: 'assabet_io_desc' defined but not used [-Wunused-variable]
static struct map_desc assabet_io_desc[] __initdata = {
^
cc1: some warnings being treated as errors
make[1]: *** [arch/arm/mach-sa1100/assabet.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [arch/arm/mach-sa1100] Error 2
make: *** Waiting for unfinished jobs....
The code there performs the manual selection of page flags which makes
it dependant on MMU.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/mach-sa1100/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-sa1100/Kconfig b/arch/arm/mach-sa1100/Kconfig
index 36e3c79..af8cd56 100644
--- a/arch/arm/mach-sa1100/Kconfig
+++ b/arch/arm/mach-sa1100/Kconfig
@@ -4,6 +4,7 @@ menu "SA11x0 Implementations"
config SA1100_ASSABET
bool "Assabet"
+ depends on MMU
select ARM_SA1110_CPUFREQ
help
Say Y here if you are using the Intel(R) StrongARM(R) SA-1110
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 20/25] ARM: i.MX: remove map_io callback
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
There is no need to define map_io only for debug_ll_io_init() since it
is already called in devicemaps_init() if map_io is NULL.
Apart from that, for NOMMU build debug_ll_io_init() is a nop which
leads to following error:
CC arch/arm/mach-imx/mach-imx1.o
arch/arm/mach-imx/mach-imx1.c:40:13: error: 'debug_ll_io_init' undeclared here (not in a function)
.map_io = debug_ll_io_init,
^
make[1]: *** [arch/arm/mach-imx/mach-imx1.o] Error 1
Cc: Alexander Shiyan <shc_work@mail.ru>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/mach-imx/mach-imx1.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-imx/mach-imx1.c b/arch/arm/mach-imx/mach-imx1.c
index de5ab8d..3a8406e 100644
--- a/arch/arm/mach-imx/mach-imx1.c
+++ b/arch/arm/mach-imx/mach-imx1.c
@@ -37,7 +37,6 @@ static void __init imx1_init_irq(void)
};
DT_MACHINE_START(IMX1_DT, "Freescale i.MX1 (Device Tree Support)")
- .map_io = debug_ll_io_init,
.init_early = imx1_init_early,
.init_irq = imx1_init_irq,
.dt_compat = imx1_dt_board_compat,
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 21/25] PCI: tegra: limit to MMU build only
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
This driver rely on MMU for virtual address space optimisations (see
comment around tegra_pcie_bus_alloc()) and breaks NOMMU build, thus
add dependency on MMU.
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
drivers/pci/host/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d7e7c0a..836fa02 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -69,7 +69,7 @@ config PCI_IMX6
config PCI_TEGRA
bool "NVIDIA Tegra PCIe controller"
- depends on ARCH_TEGRA && !ARM64
+ depends on ARCH_TEGRA && !ARM64 && MMU
help
Say Y here if you want support for the PCIe host controller found
on NVIDIA Tegra SoCs.
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 22/25] IB: add dependency on MMU
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
While building for NOMMU several link time issues were seen:
mm/built-in.o: In function `do_mmu_notifier_register':
usercopy.c:(.text+0x34d10): undefined reference to `mm_take_all_locks'
usercopy.c:(.text+0x34d9c): undefined reference to `mm_drop_all_locks'
usercopy.c:(.text+0x34de4): undefined reference to `mm_take_all_locks'
...
ERROR: "zap_vma_ptes" [drivers/infiniband/hw/mlx5/mlx5_ib.ko] undefined!
ERROR: "zap_vma_ptes" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: "can_do_mlock" [drivers/infiniband/core/ib_core.ko] undefined!
...
ERROR: "can_do_mlock" [drivers/infiniband/core/ib_core.ko] undefined!
...
ERROR: "zap_vma_ptes" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
It seems that Infiniband assumes that is it used in MMU configurations
only, so add dependency on CONFUG_MMU.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
drivers/infiniband/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig
index fb3fb89..5f17955 100644
--- a/drivers/infiniband/Kconfig
+++ b/drivers/infiniband/Kconfig
@@ -4,6 +4,7 @@ menuconfig INFINIBAND
depends on HAS_IOMEM
depends on NET
depends on INET
+ depends on MMU
depends on m || IPV6 != m
select IRQ_POLL
---help---
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 23/25] cnic: add dependency on MMU
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
CNIC selects UIO framework which has dependency on MMU, so for NOMMU
builds following warning shows up:
warning: (CNIC) selects UIO which has unmet direct dependencies (MMU)
Fix it with making CNIC dependant on MMU.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
drivers/net/ethernet/broadcom/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/broadcom/Kconfig b/drivers/net/ethernet/broadcom/Kconfig
index bd8c80c..ea04b36 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -83,6 +83,7 @@ config BNX2
config CNIC
tristate "QLogic CNIC support"
depends on PCI && (IPV6 || IPV6=n)
+ depends on MMU
select BNX2
select UIO
---help---
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 24/25] scsi: bnx2i: bnx2fc: add dependency on MMU
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
Both SCSI_BNX2_ISCSI and SCSI_BNX2X_FCOE select CNIC which it turn
select UIO. The later one is dependant on MMU, so while fixing CNIC
for NOMMU build (by adding explicit dependency on MMU) following
warning shows up:
warning: (SCSI_BNX2_ISCSI && SCSI_BNX2X_FCOE) selects CNIC which has
unmet direct dependencies (NETDEVICES && ETHERNET &&
NET_VENDOR_BROADCOM && PCI && (IPV6 || IPV6=n) && MMU)
Fix it with making SCSI_BNX2_ISCSI and SCSI_BNX2X_FCOE dependant on
MMU.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
drivers/scsi/bnx2fc/Kconfig | 1 +
drivers/scsi/bnx2i/Kconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/scsi/bnx2fc/Kconfig b/drivers/scsi/bnx2fc/Kconfig
index d401a09..7862f72 100644
--- a/drivers/scsi/bnx2fc/Kconfig
+++ b/drivers/scsi/bnx2fc/Kconfig
@@ -1,5 +1,6 @@
config SCSI_BNX2X_FCOE
tristate "QLogic FCoE offload support"
+ depends on MMU
depends on PCI
depends on (IPV6 || IPV6=n)
depends on LIBFC
diff --git a/drivers/scsi/bnx2i/Kconfig b/drivers/scsi/bnx2i/Kconfig
index ba30ff8..0549267 100644
--- a/drivers/scsi/bnx2i/Kconfig
+++ b/drivers/scsi/bnx2i/Kconfig
@@ -1,5 +1,6 @@
config SCSI_BNX2_ISCSI
tristate "QLogic NetXtreme II iSCSI support"
+ depends on MMU
depends on NET
depends on PCI
depends on (IPV6 || IPV6=n)
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 PATCH 25/25] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Vladimir Murzin @ 2016-12-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480691143-19845-1-git-send-email-vladimir.murzin@arm.com>
With this patch applied potentially any platform can be built in NOMMU
configurations if CONFIG_EXPERT is selected. However, there is no
guarantee that platform can successfully run such Image. So the main
motivation behind of this patch:
- bring build coverage for NOMMU configurations
- allow known working NOMMU platforms (like R-class) to be used
- pave a way to add support for single address space (aka 1:1 mapping)
for MMU platforms, so they can be usable in NOMMU configurations
Cc: Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ryan Mallon <rmallon@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Alexander Shiyan <shc_work@mail.ru>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/Kconfig | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b3fa6e9..9c90b81 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -327,9 +327,9 @@ choice
config ARCH_MULTIPLATFORM
bool "Allow multiple platforms to be selected"
- depends on MMU
+ depends on MMU || EXPERT
select ARM_HAS_SG_CHAIN
- select ARM_PATCH_PHYS_VIRT
+ select ARM_PATCH_PHYS_VIRT if MMU
select AUTO_ZRELADDR
select CLKSRC_OF
select COMMON_CLK
@@ -339,6 +339,23 @@ config ARCH_MULTIPLATFORM
select PCI_DOMAINS if PCI
select SPARSE_IRQ
select USE_OF
+ help
+ Please, read carefully if you've selected CONFIG_MMU=n!
+
+ Multiplatform with !MMU configuration *is not* meant that
+ kernel built to support every platform will boot on them. It
+ is because physical address space layouts (particularly where
+ RAM is located) are different between platforms and there is
+ no MMU to work that around.
+
+ You must specify where RAM start (via DRAM_BASE config
+ option) and appropriate size of RAM (via DRAM_SIZE config
+ option) which are valid for the platform you are building
+ for.
+
+ This feature is *EXPERIMENTAL*, please, consider building
+ with CONFIG_MMU=y unless you know what you do or want to
+ help with testing.
config ARM_SINGLE_ARMV7M
bool "ARMv7-M based platforms (Cortex-M0/M3/M4)"
--
1.7.9.5
^ permalink raw reply related
* [PATCH] imx_v6_v7_defconfig: enable SPIDEV module
From: Fabio Estevam @ 2016-12-02 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202145631.19292-1-gary.bisson@boundarydevices.com>
Hi Gary,
On Fri, Dec 2, 2016 at 12:56 PM, Gary Bisson
<gary.bisson@boundarydevices.com> wrote:
> Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
> ---
> Hi,
>
> Seems that this configuration is missing, especially since many
> device trees are already using "spidev" nodes.
Then they will trigger the following warning below (from the spidev
probe function):
/*
* spidev should never be referenced in DT without a specific
* compatible string, it is a Linux implementation thing
* rather than a description of the hardware.
*/
if (spi->dev.of_node && !of_match_device(spidev_dt_ids, &spi->dev)) {
dev_err(&spi->dev, "buggy DT: spidev listed directly in DT\n");
WARN_ON(spi->dev.of_node &&
!of_match_device(spidev_dt_ids, &spi->dev));
}
^ permalink raw reply
* [PATCH 1/2] arm: dts: sun8i: add uart1 node to reference design tablet
From: Icenowy Zheng @ 2016-12-02 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In the A23/A33 tablet reference design, the UART1 at PG is used to
connect to the UART-connected bluetooth.
Add a disabled uart1 node for it in the reference design tablet dtsi,
contains the pinctrl info.
If a tablet uses the UART bluetooth, simply set the status of this node
to "okay".
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
index 08cd001..2d9cf0d 100644
--- a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
@@ -46,6 +46,7 @@
/ {
aliases {
serial0 = &r_uart;
+ serial1 = &uart1;
};
backlight: backlight {
@@ -223,6 +224,13 @@
vcc-lcd-supply = <®_dc1sw>;
};
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins_a>,
+ <&uart1_pins_cts_rts_a>;
+ status = "disabled";
+};
+
&usb_otg {
dr_mode = "otg";
status = "okay";
--
2.10.2
^ permalink raw reply related
* [PATCH 2/2] arm: dts: sun8i: reuse the uart1 node of iNet D978 rev2 board
From: Icenowy Zheng @ 2016-12-02 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202151913.38892-1-icenowy@aosc.xyz>
As a uart1 node is added into sun8i-reference-design-tablet.dtsi, simply
use it in iNet D978 rev2 device tree.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
index fb46655..7335461 100644
--- a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
+++ b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
@@ -49,15 +49,6 @@
model = "INet-D978 Rev 02";
compatible = "primux,inet-d978-rev2", "allwinner,sun8i-a33";
- aliases {
- serial0 = &uart1;
- };
-
- chosen {
- /* Delete debug UART as serial0 is the UART for bluetooth */
- /delete-property/stdout-path;
- };
-
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -96,13 +87,6 @@
};
};
-&r_uart {
- status = "disabled";
-};
-
&uart1 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart1_pins_a>,
- <&uart1_pins_cts_rts_a>;
status = "okay";
};
--
2.10.2
^ permalink raw reply related
* [PATCH] imx_v6_v7_defconfig: enable SPIDEV module
From: Gary Bisson @ 2016-12-02 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5C8OH6obRn_8zh5HA9zoanRXUpoqk=vEBx+fW3wraNS6Q@mail.gmail.com>
Hi Fabio,
On Fri, Dec 02, 2016 at 01:18:42PM -0200, Fabio Estevam wrote:
> Hi Gary,
>
> On Fri, Dec 2, 2016 at 12:56 PM, Gary Bisson
> <gary.bisson@boundarydevices.com> wrote:
> > Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
> > ---
> > Hi,
> >
> > Seems that this configuration is missing, especially since many
> > device trees are already using "spidev" nodes.
>
> Then they will trigger the following warning below (from the spidev
> probe function):
>
> /*
> * spidev should never be referenced in DT without a specific
> * compatible string, it is a Linux implementation thing
> * rather than a description of the hardware.
> */
> if (spi->dev.of_node && !of_match_device(spidev_dt_ids, &spi->dev)) {
> dev_err(&spi->dev, "buggy DT: spidev listed directly in DT\n");
> WARN_ON(spi->dev.of_node &&
> !of_match_device(spidev_dt_ids, &spi->dev));
> }
Yes I've seen this WARN_ON when doing the dt-overlay testing. But is
disabling the SPIDEV configuration a solution?
To be honest I disagree with that WARN_ON. Ok it means that the hardware
isn't fully described in the device tree but for development platforms
(such as ours or any rpi-like boards) the user can design his own
daugher board with whatever SPI device on it. Then using the spidev
interface is very convenient, so I don't understand what we are trying
to forbid here.
Regards,
Gary
^ permalink raw reply
* [PATCH v9 07/16] drivers: acpi: implement acpi_dma_configure
From: Lorenzo Pieralisi @ 2016-12-02 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121100148.24769-8-lorenzo.pieralisi@arm.com>
Rafael, Mark, Suravee,
On Mon, Nov 21, 2016 at 10:01:39AM +0000, Lorenzo Pieralisi wrote:
> On DT based systems, the of_dma_configure() API implements DMA
> configuration for a given device. On ACPI systems an API equivalent to
> of_dma_configure() is missing which implies that it is currently not
> possible to set-up DMA operations for devices through the ACPI generic
> kernel layer.
>
> This patch fills the gap by introducing acpi_dma_configure/deconfigure()
> calls that for now are just wrappers around arch_setup_dma_ops() and
> arch_teardown_dma_ops() and also updates ACPI and PCI core code to use
> the newly introduced acpi_dma_configure/acpi_dma_deconfigure functions.
>
> Since acpi_dma_configure() is used to configure DMA operations, the
> function initializes the dma/coherent_dma masks to sane default values
> if the current masks are uninitialized (also to keep the default values
> consistent with DT systems) to make sure the device has a complete
> default DMA set-up.
I spotted a niggle that unfortunately was hard to spot (and should not
be a problem per se but better safe than sorry) and I am not comfortable
with it.
Following commit d0562674838c ("ACPI / scan: Parse _CCA and setup
device coherency") in acpi_bind_one() we check if the acpi_device
associated with a device just added supports DMA, first it was
done with acpi_check_dma() and then commit 1831eff876bd ("device
property: ACPI: Make use of the new DMA Attribute APIs") changed
it to acpi_get_dma_attr().
The subsequent check (attr != DEV_DMA_NOT_SUPPORTED) is always true
on _any_ acpi device we pass to acpi_bind_one() on x86, which was
fine because we used it to call arch_setup_dma_ops(), which is a nop
on x86. On ARM64 a _CCA method is required to define if a device
supports DMA so (attr != DEV_DMA_NOT_SUPPORTED) may well be false.
Now, acpi_bind_one() is used to bind an acpi_device to its physical
node also for pseudo-devices like cpus and memory nodes. For those
objects, on x86, attr will always be != DEV_DMA_NOT_SUPPORTED.
So far so good, because on x86 arch_setup_dma_ops() is empty code.
With this patch, I use the (attr != DEV_DMA_NOT_SUPPORTED) check
to call acpi_dma_configure() which is basically a nop on x86 except
that it sets up the dma_mask/coherent_dma_mask to a sane default value
(after all we are setting up DMA for the device so it makes sense to
initialize the masks there if they were unset since we are configuring
DMA for the device in question) for the given device.
Problem is, as per the explanation above, we are also setting the
default dma masks for pseudo-devices (eg CPUs) that were previously
untouched, it should not be a problem per-se but I am not comfortable
with that, honestly it does not make much sense.
An easy "fix" would be to move the default dma masks initialization out
of acpi_dma_configure() (as it was in previous patch versions of this
series - I moved it to acpi_dma_configure() just a consolidation point
for initializing the masks instead of scattering them in every
acpi_dma_configure caller) I can send this as a fix-up patch to Joerg if
we think that's the right thing to do (or I can send it to Rafael later
when the code is in the merged depending on the timing) just let me
know please.
Thanks !
Lorenzo
> The DMA range size passed to arch_setup_dma_ops() is sized according
> to the device coherent_dma_mask (starting at address 0x0), mirroring the
> DT probing path behaviour when a dma-ranges property is not provided
> for the device being probed; this changes the current arch_setup_dma_ops()
> call parameters in the ACPI probing case, but since arch_setup_dma_ops()
> is a NOP on all architectures but ARM/ARM64 this patch does not change
> the current kernel behaviour on them.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com> [pci]
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Reviewed-by: Tomasz Nowicki <tn@semihalf.com>
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> ---
> drivers/acpi/glue.c | 4 ++--
> drivers/acpi/scan.c | 40 ++++++++++++++++++++++++++++++++++++++++
> drivers/pci/probe.c | 3 +--
> include/acpi/acpi_bus.h | 2 ++
> include/linux/acpi.h | 5 +++++
> 5 files changed, 50 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> index 5ea5dc2..f8d6564 100644
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -227,8 +227,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
>
> attr = acpi_get_dma_attr(acpi_dev);
> if (attr != DEV_DMA_NOT_SUPPORTED)
> - arch_setup_dma_ops(dev, 0, 0, NULL,
> - attr == DEV_DMA_COHERENT);
> + acpi_dma_configure(dev, attr);
>
> acpi_physnode_link_name(physical_node_name, node_id);
> retval = sysfs_create_link(&acpi_dev->dev.kobj, &dev->kobj,
> @@ -251,6 +250,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
> return 0;
>
> err:
> + acpi_dma_deconfigure(dev);
> ACPI_COMPANION_SET(dev, NULL);
> put_device(dev);
> put_device(&acpi_dev->dev);
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 3d1856f..45b5710 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1370,6 +1370,46 @@ enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
> return DEV_DMA_NON_COHERENT;
> }
>
> +/**
> + * acpi_dma_configure - Set-up DMA configuration for the device.
> + * @dev: The pointer to the device
> + * @attr: device dma attributes
> + */
> +void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
> +{
> + /*
> + * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> + * setup the correct supported mask.
> + */
> + if (!dev->coherent_dma_mask)
> + dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +
> + /*
> + * Set it to coherent_dma_mask by default if the architecture
> + * code has not set it.
> + */
> + if (!dev->dma_mask)
> + dev->dma_mask = &dev->coherent_dma_mask;
> +
> + /*
> + * Assume dma valid range starts at 0 and covers the whole
> + * coherent_dma_mask.
> + */
> + arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, NULL,
> + attr == DEV_DMA_COHERENT);
> +}
> +EXPORT_SYMBOL_GPL(acpi_dma_configure);
> +
> +/**
> + * acpi_dma_deconfigure - Tear-down DMA configuration for the device.
> + * @dev: The pointer to the device
> + */
> +void acpi_dma_deconfigure(struct device *dev)
> +{
> + arch_teardown_dma_ops(dev);
> +}
> +EXPORT_SYMBOL_GPL(acpi_dma_deconfigure);
> +
> static void acpi_init_coherency(struct acpi_device *adev)
> {
> unsigned long long cca = 0;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index ab00267..c29e07a 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1738,8 +1738,7 @@ static void pci_dma_configure(struct pci_dev *dev)
> if (attr == DEV_DMA_NOT_SUPPORTED)
> dev_warn(&dev->dev, "DMA not supported.\n");
> else
> - arch_setup_dma_ops(&dev->dev, 0, 0, NULL,
> - attr == DEV_DMA_COHERENT);
> + acpi_dma_configure(&dev->dev, attr);
> }
>
> pci_put_host_bridge_device(bridge);
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index c1a524d..4242c31 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -573,6 +573,8 @@ struct acpi_pci_root {
>
> bool acpi_dma_supported(struct acpi_device *adev);
> enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev);
> +void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr);
> +void acpi_dma_deconfigure(struct device *dev);
>
> struct acpi_device *acpi_find_child_device(struct acpi_device *parent,
> u64 address, bool check_children);
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 996a29c..8d15fc5 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -765,6 +765,11 @@ static inline enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
> return DEV_DMA_NOT_SUPPORTED;
> }
>
> +static inline void acpi_dma_configure(struct device *dev,
> + enum dev_dma_attr attr) { }
> +
> +static inline void acpi_dma_deconfigure(struct device *dev) { }
> +
> #define ACPI_PTR(_ptr) (NULL)
>
> static inline void acpi_device_set_enumerated(struct acpi_device *adev)
> --
> 2.10.0
>
^ permalink raw reply
* [PATCH v2 0/3] ARM: da850: fix pll0 rate setting
From: Bartosz Golaszewski @ 2016-12-02 15:38 UTC (permalink / raw)
To: linux-arm-kernel
While trying to set the pll0 rate from the kernel I noticed there are
two issues with da850 clocks. The first patch fixes an infinite loop
in propagate_rate(). The third fixes an oops in da850_set_pll0rate().
The second patch is just a coding style fix, while we're at it.
v1 -> v2:
- change the approach in 1/3: create a new clock for nand inheriting
the rate from the aemif clock (verified that nand still works on
da850-lcdk)
- patch 3/3: also update the davinci_cpufreq driver - the only
(indirect) user of da850_set_pll0rate()
- s/requested_rate/rate in 3/3
Bartosz Golaszewski (3):
ARM: da850: fix infinite loop in clk_set_rate()
ARM: da850: coding style fix
ARM: da850: fix da850_set_pll0rate()
arch/arm/mach-davinci/da850.c | 31 +++++++++++++++++++++++++------
drivers/cpufreq/davinci-cpufreq.c | 2 +-
drivers/mtd/nand/davinci_nand.c | 2 +-
3 files changed, 27 insertions(+), 8 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v2 1/3] ARM: da850: fix infinite loop in clk_set_rate()
From: Bartosz Golaszewski @ 2016-12-02 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480693134-31324-1-git-send-email-bgolaszewski@baylibre.com>
The aemif clock is added twice to the lookup table in da850.c. This
breaks the children list of pll0_sysclk3 as we're using the same list
links in struct clk. When calling clk_set_rate(), we get stuck in
propagate_rate().
Create a separate clock for nand, inheriting the rate of the aemif
clock and retrieve it in the davinci_nand module.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/da850.c | 7 ++++++-
drivers/mtd/nand/davinci_nand.c | 2 +-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index e770c97..1fcc986 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -367,6 +367,11 @@ static struct clk aemif_clk = {
.flags = ALWAYS_ENABLED,
};
+static struct clk nand_clk = {
+ .name = "nand",
+ .parent = &aemif_clk,
+};
+
static struct clk usb11_clk = {
.name = "usb11",
.parent = &pll0_sysclk4,
@@ -537,7 +542,7 @@ static struct clk_lookup da850_clks[] = {
CLK("da830-mmc.0", NULL, &mmcsd0_clk),
CLK("da830-mmc.1", NULL, &mmcsd1_clk),
CLK("ti-aemif", NULL, &aemif_clk),
- CLK(NULL, "aemif", &aemif_clk),
+ CLK(NULL, "nand", &nand_clk),
CLK("ohci-da8xx", "usb11", &usb11_clk),
CLK("musb-da8xx", "usb20", &usb20_clk),
CLK("spi_davinci.0", NULL, &spi0_clk),
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 27fa8b8..5857d06 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -694,7 +694,7 @@ static int nand_davinci_probe(struct platform_device *pdev)
ret = -EINVAL;
- info->clk = devm_clk_get(&pdev->dev, "aemif");
+ info->clk = devm_clk_get(&pdev->dev, "nand");
if (IS_ERR(info->clk)) {
ret = PTR_ERR(info->clk);
dev_dbg(&pdev->dev, "unable to get AEMIF clock, err %d\n", ret);
--
2.9.3
^ permalink raw reply related
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