* [RFCv3][PATCH 3/5] arm64: Implement ARCH_HAS_FORCE_CACHE
From: Laura Abbott @ 2016-09-12 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473715978-11633-1-git-send-email-labbott@redhat.com>
arm64 may need to guarantee the caches are synced. Implement versions of
the kernel_force_cache API to allow this.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v3: Switch to calling cache operations directly instead of relying on
DMA mapping.
---
arch/arm64/include/asm/cacheflush.h | 8 ++++++++
arch/arm64/mm/cache.S | 24 ++++++++++++++++++++----
arch/arm64/mm/flush.c | 11 +++++++++++
3 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/cacheflush.h b/arch/arm64/include/asm/cacheflush.h
index c64268d..1134c15 100644
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@ -87,6 +87,9 @@ extern void __dma_map_area(const void *, size_t, int);
extern void __dma_unmap_area(const void *, size_t, int);
extern void __dma_flush_range(const void *, const void *);
+extern void __force_dcache_clean(const void *, size_t);
+extern void __force_dcache_invalidate(const void *, size_t);
+
/*
* Copy user data from/to a page which is mapped into a different
* processes address space. Really, we want to allow our "user
@@ -149,4 +152,9 @@ int set_memory_rw(unsigned long addr, int numpages);
int set_memory_x(unsigned long addr, int numpages);
int set_memory_nx(unsigned long addr, int numpages);
+#define ARCH_HAS_FORCE_CACHE 1
+
+void kernel_force_cache_clean(struct page *page, size_t size);
+void kernel_force_cache_invalidate(struct page *page, size_t size);
+
#endif
diff --git a/arch/arm64/mm/cache.S b/arch/arm64/mm/cache.S
index 07d7352..e99c9a4 100644
--- a/arch/arm64/mm/cache.S
+++ b/arch/arm64/mm/cache.S
@@ -184,10 +184,6 @@ ENDPIPROC(__dma_flush_range)
* - dir - DMA direction
*/
ENTRY(__dma_map_area)
- add x1, x1, x0
- cmp w2, #DMA_FROM_DEVICE
- b.eq __dma_inv_range
- b __dma_clean_range
ENDPIPROC(__dma_map_area)
/*
@@ -202,3 +198,23 @@ ENTRY(__dma_unmap_area)
b.ne __dma_inv_range
ret
ENDPIPROC(__dma_unmap_area)
+
+/*
+ * __force_dcache_clean(start, size)
+ * - start - kernel virtual start address
+ * - size - size of region
+ */
+ENTRY(__force_dcache_clean)
+ add x1, x1, x0
+ b __dma_clean_range
+ENDPROC(__force_dcache_clean)
+
+/*
+ * __force_dcache_invalidate(start, size)
+ * - start - kernel virtual start address
+ * - size - size of region
+ */
+ENTRY(__force_dcache_invalidate)
+ add x1, x1, x0
+ b __dma_inv_range
+ENDPROC(__force_dcache_invalidate)
diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c
index 43a76b0..54ff32e 100644
--- a/arch/arm64/mm/flush.c
+++ b/arch/arm64/mm/flush.c
@@ -20,6 +20,7 @@
#include <linux/export.h>
#include <linux/mm.h>
#include <linux/pagemap.h>
+#include <linux/dma-mapping.h>
#include <asm/cacheflush.h>
#include <asm/cachetype.h>
@@ -94,3 +95,13 @@ EXPORT_SYMBOL(flush_dcache_page);
* Additional functions defined in assembly.
*/
EXPORT_SYMBOL(flush_icache_range);
+
+void kernel_force_cache_clean(struct page *page, size_t size)
+{
+ __force_dcache_clean(page_address(page), size);
+}
+
+void kernel_force_cache_invalidate(struct page *page, size_t size)
+{
+ __force_dcache_invalidate(page_address(page), size);
+}
--
2.7.4
^ permalink raw reply related
* [RFCv3][PATCH 2/5] arm: Impelment ARCH_HAS_FORCE_CACHE
From: Laura Abbott @ 2016-09-12 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473715978-11633-1-git-send-email-labbott@redhat.com>
arm64 may need to guarantee the caches are synced. Implement
versions of the kernel_force_cache API for v7. Other versions
are stubbed out and can be added as appropriate.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v3: Switch to force implementations per CPU instead of relying
on dma_map/dma_unmap. v7 is the only one implemented right
now, others can be added as needed.
---
arch/arm/include/asm/cacheflush.h | 11 ++++++
arch/arm/include/asm/glue-cache.h | 2 ++
arch/arm/mm/Makefile | 2 +-
arch/arm/mm/cache-fa.S | 8 +++++
arch/arm/mm/cache-nop.S | 6 ++++
arch/arm/mm/cache-v4.S | 10 ++++++
arch/arm/mm/cache-v4wb.S | 8 +++++
arch/arm/mm/cache-v4wt.S | 8 +++++
arch/arm/mm/cache-v6.S | 8 +++++
arch/arm/mm/cache-v7.S | 13 +++++++
arch/arm/mm/cacheflush.c | 71 +++++++++++++++++++++++++++++++++++++++
arch/arm/mm/proc-arm920.S | 8 +++++
arch/arm/mm/proc-arm922.S | 8 +++++
arch/arm/mm/proc-arm925.S | 8 +++++
arch/arm/mm/proc-arm926.S | 8 +++++
arch/arm/mm/proc-feroceon.S | 11 ++++++
arch/arm/mm/proc-macros.S | 2 ++
arch/arm/mm/proc-xsc3.S | 9 +++++
arch/arm/mm/proc-xscale.S | 9 +++++
19 files changed, 209 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mm/cacheflush.c
diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
index 9156fc3..2d9a4d3 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -116,6 +116,9 @@ struct cpu_cache_fns {
void (*dma_unmap_area)(const void *, size_t, int);
void (*dma_flush_range)(const void *, const void *);
+
+ void (*force_dcache_clean)(void *, size_t);
+ void (*force_dcache_invalidate)(void *, size_t);
};
/*
@@ -133,6 +136,8 @@ extern struct cpu_cache_fns cpu_cache;
#define __cpuc_coherent_kern_range cpu_cache.coherent_kern_range
#define __cpuc_coherent_user_range cpu_cache.coherent_user_range
#define __cpuc_flush_dcache_area cpu_cache.flush_kern_dcache_area
+#define __cpuc_force_dcache_clean cpu_cache.force_dcache_clean
+#define __cpuc_force_dcache_invalidate cpu_cache.force_dcache_invalidate
/*
* These are private to the dma-mapping API. Do not use directly.
@@ -152,6 +157,8 @@ extern void __cpuc_flush_user_range(unsigned long, unsigned long, unsigned int);
extern void __cpuc_coherent_kern_range(unsigned long, unsigned long);
extern int __cpuc_coherent_user_range(unsigned long, unsigned long);
extern void __cpuc_flush_dcache_area(void *, size_t);
+extern void __cpuc_force_dcache_clean(void *, size_t);
+extern void __cpuc_force_dcache_invalidate(void *, size_t);
/*
* These are private to the dma-mapping API. Do not use directly.
@@ -518,4 +525,8 @@ static inline void secure_flush_area(const void *addr, size_t size)
outer_flush_range(phys, phys + size);
}
+#define ARCH_HAS_FORCE_CACHE 1
+void kernel_force_cache_clean(struct page *page, size_t size);
+void kernel_force_cache_invalidate(struct page *page, size_t size);
+
#endif
diff --git a/arch/arm/include/asm/glue-cache.h b/arch/arm/include/asm/glue-cache.h
index cab07f6..232938f 100644
--- a/arch/arm/include/asm/glue-cache.h
+++ b/arch/arm/include/asm/glue-cache.h
@@ -157,6 +157,8 @@ static inline void nop_dma_unmap_area(const void *s, size_t l, int f) { }
#define __cpuc_coherent_kern_range __glue(_CACHE,_coherent_kern_range)
#define __cpuc_coherent_user_range __glue(_CACHE,_coherent_user_range)
#define __cpuc_flush_dcache_area __glue(_CACHE,_flush_kern_dcache_area)
+#define __cpuc_force_dcache_clean __glue(_CACHE,_force_dcache_clean)
+#define __cpuc_force_dcache_invalidate __glue(_CACHE,_force_dcache_invalidate)
#define dmac_flush_range __glue(_CACHE,_dma_flush_range)
#endif
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 7f76d96..3afcdd0 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -3,7 +3,7 @@
#
obj-y := dma-mapping.o extable.o fault.o init.o \
- iomap.o
+ iomap.o cacheflush.o
obj-$(CONFIG_MMU) += fault-armv.o flush.o idmap.o ioremap.o \
mmap.o pgd.o mmu.o pageattr.o
diff --git a/arch/arm/mm/cache-fa.S b/arch/arm/mm/cache-fa.S
index 2f0c588..f1fe5df 100644
--- a/arch/arm/mm/cache-fa.S
+++ b/arch/arm/mm/cache-fa.S
@@ -244,6 +244,14 @@ ENDPROC(fa_dma_unmap_area)
.globl fa_flush_kern_cache_louis
.equ fa_flush_kern_cache_louis, fa_flush_kern_cache_all
+ENTRY(fa_force_dcache_invalidate)
+ ret lr
+ENDPROC(fa_force_dcache_invalidate)
+
+ENTRY(fa_force_dcache_clean)
+ ret lr
+ENDPROC(fa_force_dcache_clean)
+
__INITDATA
@ define struct cpu_cache_fns (see <asm/cacheflush.h> and proc-macros.S)
diff --git a/arch/arm/mm/cache-nop.S b/arch/arm/mm/cache-nop.S
index f1cc986..983f96f 100644
--- a/arch/arm/mm/cache-nop.S
+++ b/arch/arm/mm/cache-nop.S
@@ -45,6 +45,12 @@ ENDPROC(nop_coherent_user_range)
.globl nop_dma_unmap_area
.equ nop_dma_unmap_area, nop_flush_icache_all
+ .globl nop_force_dcache_clean
+ .equ nop_force_dcache_clean, nop_flush_icache_all
+
+ .globl nop_force_dcache_invalidate
+ .equ nop_force_dcache_invalidate, nop_flush_icache_all
+
__INITDATA
@ define struct cpu_cache_fns (see <asm/cacheflush.h> and proc-macros.S)
diff --git a/arch/arm/mm/cache-v4.S b/arch/arm/mm/cache-v4.S
index 91e3adf..db07995 100644
--- a/arch/arm/mm/cache-v4.S
+++ b/arch/arm/mm/cache-v4.S
@@ -144,6 +144,16 @@ ENDPROC(v4_dma_map_area)
.globl v4_flush_kern_cache_louis
.equ v4_flush_kern_cache_louis, v4_flush_kern_cache_all
+
+ENTRY(v4_force_dcache_invalidate)
+ ret lr
+ENDPROC(v4_force_dcache_invalidate)
+
+ENTRY(v4_force_dcache_clean)
+ ret lr
+ENDPROC(v4_force_dcache_clean)
+
+
__INITDATA
@ define struct cpu_cache_fns (see <asm/cacheflush.h> and proc-macros.S)
diff --git a/arch/arm/mm/cache-v4wb.S b/arch/arm/mm/cache-v4wb.S
index 2522f8c..897f333 100644
--- a/arch/arm/mm/cache-v4wb.S
+++ b/arch/arm/mm/cache-v4wb.S
@@ -255,6 +255,14 @@ ENDPROC(v4wb_dma_unmap_area)
.globl v4wb_flush_kern_cache_louis
.equ v4wb_flush_kern_cache_louis, v4wb_flush_kern_cache_all
+ENTRY(v4wb_force_dcache_invalidate)
+ ret lr
+ENDPROC(v4wb_force_dcache_invalidate)
+
+ENTRY(v4wb_force_dcache_clean)
+ ret lr
+ENDPROC(v4wb_force_dcache_clean)
+
__INITDATA
@ define struct cpu_cache_fns (see <asm/cacheflush.h> and proc-macros.S)
diff --git a/arch/arm/mm/cache-v4wt.S b/arch/arm/mm/cache-v4wt.S
index a0982ce..2e77e4a 100644
--- a/arch/arm/mm/cache-v4wt.S
+++ b/arch/arm/mm/cache-v4wt.S
@@ -200,6 +200,14 @@ ENDPROC(v4wt_dma_map_area)
.globl v4wt_flush_kern_cache_louis
.equ v4wt_flush_kern_cache_louis, v4wt_flush_kern_cache_all
+ENTRY(v4wt_force_dcache_invalidate)
+ ret lr
+ENDPROC(v4wt_force_dcache_invalidate)
+
+ENTRY(v4wt_force_dcache_clean)
+ ret lr
+ENDPROC(v4wt_force_dcache_clean)
+
__INITDATA
@ define struct cpu_cache_fns (see <asm/cacheflush.h> and proc-macros.S)
diff --git a/arch/arm/mm/cache-v6.S b/arch/arm/mm/cache-v6.S
index 2465995..4911634 100644
--- a/arch/arm/mm/cache-v6.S
+++ b/arch/arm/mm/cache-v6.S
@@ -333,3 +333,11 @@ ENDPROC(v6_dma_unmap_area)
@ define struct cpu_cache_fns (see <asm/cacheflush.h> and proc-macros.S)
define_cache_functions v6
+
+ENTRY(v6_force_dcache_invalidate)
+ ret lr
+ENDPROC(v6_force_dcache_invalidate)
+
+ENTRY(v6_force_dcache_clean)
+ ret lr
+ENDPROC(v6_force_dcache_clean)
diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
index a134d8a..2750b27 100644
--- a/arch/arm/mm/cache-v7.S
+++ b/arch/arm/mm/cache-v7.S
@@ -442,6 +442,19 @@ ENTRY(v7_dma_unmap_area)
ret lr
ENDPROC(v7_dma_unmap_area)
+
+ENTRY(v7_force_dcache_invalidate)
+ add r1, r1, r0
+ b v7_dma_inv_range
+ ret lr
+ENDPROC(v7_force_dcache_invalidate)
+
+ENTRY(v7_force_dcache_clean)
+ add r1, r1, r0
+ b v7_dma_clean_range
+ ret lr
+ENDPROC(v7_force_dcache_clean)
+
__INITDATA
@ define struct cpu_cache_fns (see <asm/cacheflush.h> and proc-macros.S)
diff --git a/arch/arm/mm/cacheflush.c b/arch/arm/mm/cacheflush.c
new file mode 100644
index 0000000..5daa98e
--- /dev/null
+++ b/arch/arm/mm/cacheflush.c
@@ -0,0 +1,71 @@
+/*
+ * Based on arch/arm/mm/dma-mapping.c which is
+ * Copyright (C) 2000-2004 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/highmem.h>
+
+#include <asm/highmem.h>
+#include <asm/cacheflush.h>
+
+static void __force_cache_op(struct page *page, size_t size,
+ void (*op)(void *start, size_t size))
+{
+ unsigned long pfn;
+ size_t left = size;
+
+ pfn = page_to_pfn(page);
+
+ do {
+ size_t len = left;
+ void *vaddr;
+
+ page = pfn_to_page(pfn);
+
+ if (PageHighMem(page)) {
+ if (len > PAGE_SIZE)
+ len = PAGE_SIZE;
+ if (cache_is_vipt_nonaliasing()) {
+ vaddr = kmap_atomic(page);
+ op(vaddr, len);
+ kunmap_atomic(vaddr);
+ } else {
+ vaddr = kmap_high_get(page);
+ if (vaddr) {
+ op(vaddr, len);
+ kunmap_high(page);
+ }
+ }
+ } else {
+
+ op(page_address(page), len);
+ }
+ pfn++;
+ left -= len;
+ } while(left);
+}
+
+void kernel_force_cache_clean(struct page *page, size_t size)
+{
+ phys_addr_t paddr;
+
+ paddr = page_to_phys(page);
+ __force_cache_op(page, size, __cpuc_force_dcache_clean);
+ outer_clean_range(paddr, paddr + size);
+}
+
+void kernel_force_cache_invalidate(struct page *page, size_t size)
+{
+ phys_addr_t paddr;
+
+ paddr = page_to_phys(page);
+ __force_cache_op(page, size, __cpuc_force_dcache_invalidate);
+ outer_inv_range(paddr, paddr + size);
+}
diff --git a/arch/arm/mm/proc-arm920.S b/arch/arm/mm/proc-arm920.S
index 7a14bd4..ead3060 100644
--- a/arch/arm/mm/proc-arm920.S
+++ b/arch/arm/mm/proc-arm920.S
@@ -334,6 +334,14 @@ ENTRY(cpu_arm920_dcache_clean_area)
bhi 1b
ret lr
+ENTRY(arm920_force_dcache_invalidate)
+ ret lr
+ENDPROC(arm920_force_dcache_invalidate)
+
+ENTRY(arm920_force_dcache_clean)
+ ret lr
+ENDPROC(arm920_force_dcache_clean)
+
/* =============================== PageTable ============================== */
/*
diff --git a/arch/arm/mm/proc-arm922.S b/arch/arm/mm/proc-arm922.S
index edccfcd..4645a98 100644
--- a/arch/arm/mm/proc-arm922.S
+++ b/arch/arm/mm/proc-arm922.S
@@ -338,6 +338,14 @@ ENTRY(cpu_arm922_dcache_clean_area)
#endif
ret lr
+ENTRY(arm922_force_dcache_invalidate)
+ ret lr
+ENDPROC(arm922_force_dcache_invalidate)
+
+ENTRY(arm922_force_dcache_clean)
+ ret lr
+ENDPROC(arm922_force_dcache_clean)
+
/* =============================== PageTable ============================== */
/*
diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S
index 32a47cc..866d623 100644
--- a/arch/arm/mm/proc-arm925.S
+++ b/arch/arm/mm/proc-arm925.S
@@ -392,6 +392,14 @@ ENTRY(cpu_arm925_dcache_clean_area)
mcr p15, 0, r0, c7, c10, 4 @ drain WB
ret lr
+ENTRY(arm925_force_dcache_invalidate)
+ ret lr
+ENDPROC(arm925_force_dcache_invalidate)
+
+ENTRY(arm925_force_dcache_clean)
+ ret lr
+ENDPROC(arm925_force_dcache_clean)
+
/* =============================== PageTable ============================== */
/*
diff --git a/arch/arm/mm/proc-arm926.S b/arch/arm/mm/proc-arm926.S
index fb827c6..2257b00 100644
--- a/arch/arm/mm/proc-arm926.S
+++ b/arch/arm/mm/proc-arm926.S
@@ -355,6 +355,14 @@ ENTRY(cpu_arm926_dcache_clean_area)
mcr p15, 0, r0, c7, c10, 4 @ drain WB
ret lr
+ENTRY(arm926_force_dcache_invalidate)
+ ret lr
+ENDPROC(arm926_force_dcache_invalidate)
+
+ENTRY(arm926_force_dcache_clean)
+ ret lr
+ENDPROC(arm926_force_dcache_clean)
+
/* =============================== PageTable ============================== */
/*
diff --git a/arch/arm/mm/proc-feroceon.S b/arch/arm/mm/proc-feroceon.S
index 92e08bf..fca0e42 100644
--- a/arch/arm/mm/proc-feroceon.S
+++ b/arch/arm/mm/proc-feroceon.S
@@ -439,6 +439,8 @@ ENDPROC(feroceon_dma_unmap_area)
range_alias coherent_kern_range
range_alias coherent_user_range
range_alias dma_unmap_area
+ range_alias force_dcache_clean
+ range_alias force_dcache_invalidate
define_cache_functions feroceon_range
@@ -463,6 +465,15 @@ ENTRY(cpu_feroceon_dcache_clean_area)
mcr p15, 0, r0, c7, c10, 4 @ drain WB
ret lr
+ENTRY(feroceon_force_dcache_invalidate)
+ ret lr
+ENDPROC(feroceon_force_dcache_invalidate)
+
+ENTRY(feroceon_force_dcache_clean)
+ ret lr
+ENDPROC(feroceon_force_dcache_clean)
+
+
/* =============================== PageTable ============================== */
/*
diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
index c671f34..cc2d6cf 100644
--- a/arch/arm/mm/proc-macros.S
+++ b/arch/arm/mm/proc-macros.S
@@ -310,6 +310,8 @@ ENTRY(\name\()_cache_fns)
.long \name\()_dma_map_area
.long \name\()_dma_unmap_area
.long \name\()_dma_flush_range
+ .long \name\()_force_dcache_clean
+ .long \name\()_force_dcache_invalidate
.size \name\()_cache_fns, . - \name\()_cache_fns
.endm
diff --git a/arch/arm/mm/proc-xsc3.S b/arch/arm/mm/proc-xsc3.S
index 293dcc2..924d304 100644
--- a/arch/arm/mm/proc-xsc3.S
+++ b/arch/arm/mm/proc-xsc3.S
@@ -343,6 +343,15 @@ ENDPROC(xsc3_dma_unmap_area)
@ define struct cpu_cache_fns (see <asm/cacheflush.h> and proc-macros.S)
define_cache_functions xsc3
+ENTRY(xsc3_force_dcache_clean)
+ ret lr
+ENDPROC(xsc3_force_dcache_clean)
+
+ENTRY(xsc3_force_dcache_invalidate)
+ ret lr
+ENDPROC(xsc3_force_dcache_invalidate)
+
+
ENTRY(cpu_xsc3_dcache_clean_area)
1: mcr p15, 0, r0, c7, c10, 1 @ clean L1 D line
add r0, r0, #CACHELINESIZE
diff --git a/arch/arm/mm/proc-xscale.S b/arch/arm/mm/proc-xscale.S
index b6bbfdb..a8f4c74 100644
--- a/arch/arm/mm/proc-xscale.S
+++ b/arch/arm/mm/proc-xscale.S
@@ -449,6 +449,8 @@ ENDPROC(xscale_dma_unmap_area)
a0_alias flush_kern_dcache_area
a0_alias dma_flush_range
a0_alias dma_unmap_area
+ a0_alias force_dcache_clean
+ a0_alias force_dcache_invalidate
@ define struct cpu_cache_fns (see <asm/cacheflush.h> and proc-macros.S)
define_cache_functions xscale_80200_A0_A1
@@ -460,6 +462,13 @@ ENTRY(cpu_xscale_dcache_clean_area)
bhi 1b
ret lr
+ENTRY(xscale_force_dcache_invalidate)
+ ret lr
+ENDPROC(xscale_force_dcache_invalidate)
+
+ENTRY(xscale_force_dcache_clean)
+ ret lr
+ENDPROC(xscale_force_dcache_clean)
/* =============================== PageTable ============================== */
/*
--
2.7.4
^ permalink raw reply related
* [RFCv3][PATCH 1/5] Documentation: Introduce kernel_force_cache_* APIs
From: Laura Abbott @ 2016-09-12 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473715978-11633-1-git-send-email-labbott@redhat.com>
Some frameworks (e.g. Ion) may need to do explicit cache management
to meet performance/correctness requirements. Rather than piggy-back
on another API and hope the semantics don't change, introduce a
set of APIs to force a page to be cleaned/invalidated in the cache.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
Documentation/cachetlb.txt | 18 +++++++++++++++++-
include/linux/cacheflush.h | 11 +++++++++++
2 files changed, 28 insertions(+), 1 deletion(-)
create mode 100644 include/linux/cacheflush.h
diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt
index 3f9f808..18eec7c 100644
--- a/Documentation/cachetlb.txt
+++ b/Documentation/cachetlb.txt
@@ -378,7 +378,7 @@ maps this page at its virtual address.
flush_dcache_page and update_mmu_cache. In the future, the hope
is to remove this interface completely.
-The final category of APIs is for I/O to deliberately aliased address
+Another set of APIs is for I/O to deliberately aliased address
ranges inside the kernel. Such aliases are set up by use of the
vmap/vmalloc API. Since kernel I/O goes via physical pages, the I/O
subsystem assumes that the user mapping and kernel offset mapping are
@@ -401,3 +401,19 @@ I/O and invalidating it after the I/O returns.
speculatively reading data while the I/O was occurring to the
physical pages. This is only necessary for data reads into the
vmap area.
+
+Nearly all drivers can handle cache management using the existing DMA model.
+There may be limited circumstances when a driver or framework needs to
+explicitly manage the cache; trying to force cache management into the DMA
+framework may lead to performance loss or unnecessary work. These APIs may
+be used to provide explicit coherency for memory that does not fall into
+any of the above categories. Implementers of this API must assume the
+address can be aliased. Any cache operations shall not be delayed and must
+be completed by the time the call returns.
+
+ void kernel_force_cache_clean(struct page *page, size_t size);
+ Ensures that any data in the cache by the page is written back
+ and visible across all aliases.
+
+ void kernel_force_cache_invalidate(struct page *page, size_t size);
+ Invalidates the cache for the given page.
diff --git a/include/linux/cacheflush.h b/include/linux/cacheflush.h
new file mode 100644
index 0000000..4388846
--- /dev/null
+++ b/include/linux/cacheflush.h
@@ -0,0 +1,11 @@
+#ifndef CACHEFLUSH_H
+#define CACHEFLUSH_H
+
+#include <asm/cacheflush.h>
+
+#ifndef ARCH_HAS_FORCE_CACHE
+static inline void kernel_force_cache_clean(struct page *page, size_t size) { }
+static inline void kernel_force_cache_invalidate(struct page *page, size_t size) { }
+#endif
+
+#endif
--
2.7.4
^ permalink raw reply related
* [RFCv3][PATCH 0/5] Cleanup Ion mapping/caching
From: Laura Abbott @ 2016-09-12 21:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is v3 on the attempt to remove the misuse of the DMA cache APIS from Ion.
As from before:
The APIs created are kernel_force_cache_clean and kernel_force_cache_invalidate.
They force a clean and invalidate of the cache, respectively. The aim was to
take the semantics of dma_sync and turn them into something that isn't
dma_sync. This series includes a nominal implementation for arm/arm64, mostly
for demonstration purposes.
The major change from v2 is that the implementations no longer leverage the
DMA abstractions. Russell King noted that dma_map and dma_unmap just 'happen'
to do the right thing but they aren't guaranteed.
I'm hoping at v3 there are no objections to the general concept but if they
exist please express them.
Thanks,
Laura
[1]http://www.mail-archive.com/driverdev-devel at linuxdriverproject.org/msg49406.html
Laura Abbott (5):
Documentation: Introduce kernel_force_cache_* APIs
arm: Impelment ARCH_HAS_FORCE_CACHE
arm64: Implement ARCH_HAS_FORCE_CACHE
staging: android: ion: Convert to the kernel_force_cache APIs
staging: ion: Add support for syncing with DMA_BUF_IOCTL_SYNC
Documentation/cachetlb.txt | 18 ++++++-
arch/arm/include/asm/cacheflush.h | 11 ++++
arch/arm/include/asm/glue-cache.h | 2 +
arch/arm/mm/Makefile | 2 +-
arch/arm/mm/cache-fa.S | 8 +++
arch/arm/mm/cache-nop.S | 6 +++
arch/arm/mm/cache-v4.S | 10 ++++
arch/arm/mm/cache-v4wb.S | 8 +++
arch/arm/mm/cache-v4wt.S | 8 +++
arch/arm/mm/cache-v6.S | 8 +++
arch/arm/mm/cache-v7.S | 13 +++++
arch/arm/mm/cacheflush.c | 71 +++++++++++++++++++++++++
arch/arm/mm/proc-arm920.S | 8 +++
arch/arm/mm/proc-arm922.S | 8 +++
arch/arm/mm/proc-arm925.S | 8 +++
arch/arm/mm/proc-arm926.S | 8 +++
arch/arm/mm/proc-feroceon.S | 11 ++++
arch/arm/mm/proc-macros.S | 2 +
arch/arm/mm/proc-xsc3.S | 9 ++++
arch/arm/mm/proc-xscale.S | 9 ++++
arch/arm64/include/asm/cacheflush.h | 8 +++
arch/arm64/mm/cache.S | 24 +++++++--
arch/arm64/mm/flush.c | 11 ++++
drivers/staging/android/ion/ion.c | 53 +++++++++++-------
drivers/staging/android/ion/ion_carveout_heap.c | 8 +--
drivers/staging/android/ion/ion_chunk_heap.c | 12 +++--
drivers/staging/android/ion/ion_page_pool.c | 7 +--
drivers/staging/android/ion/ion_priv.h | 11 ----
drivers/staging/android/ion/ion_system_heap.c | 6 +--
include/linux/cacheflush.h | 11 ++++
30 files changed, 330 insertions(+), 49 deletions(-)
create mode 100644 arch/arm/mm/cacheflush.c
create mode 100644 include/linux/cacheflush.h
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] misc: Add Aspeed BT IPMI host driver
From: Cédric Le Goater @ 2016-09-12 21:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7db5ada0-49ea-55eb-089e-d979941ceff5@gmail.com>
Hello,
On 09/12/2016 10:33 PM, Corey Minyard wrote:
> On 09/12/2016 02:15 PM, Arnd Bergmann wrote:
>> On Monday, September 12, 2016 1:55:40 PM CEST Corey Minyard wrote:
>>> On 09/02/2016 08:22 AM, C?dric Le Goater wrote:
>>>> Hello,
>>>>
>>>> Adding Corey in cc: . I guess I should have done that in the first place.
>>> Yes, probably so. I've been travelling and didn't see it on the mailing
>>> lists until now.
>>>
>>> There is already a BT driver in the kernel, in drivers/char/ipmi, why
>>> won't that work?
>> The new driver is the host side (running on the BMC), the existing one
>> is the client (running on the PC).
>>
>> Arnd
>
> Ok, that's not really clear from the documentation or the Kconfig.
> In the IPMI spec the "host" side is the computer side, not the BMC
> side. Like:
>
> 11.6.1 BT Host Interface Registers
> The Host BT interface provides an independent set of registers and
> interrupts to allow the Host driver to
> communicate with the baseboard management controller without
> conflicting with the O/S ACPI driver.
>
> In light of that, this should probably be named the bt-bmc driver.
>
> I haven't reviewed this in detail, but I'm ok with putting it in
> drivers/char/ipmi. The state machine part looks reasonably
> generic. The configuration part isn't, but that could be split
> out later if necessary.
>
> The biggest thing I don't like is the byte at a time interfaces
> from userspace. That seems fairly inefficient if the system
> does extra work for each userspace access. IIRC some
> systems do and some don't.
What about the ioctl to send an SMS ATN event to the host ? Is
that ok for you ?
Thanks,
C.
^ permalink raw reply
* [PATCH 6/8 v2] arm: orion5x: Add DT-based support for Netgear WNR854T
From: Arnd Bergmann @ 2016-09-12 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2920481.EgEQnLmOkM@wuerfel>
On Monday, September 12, 2016 11:13:33 PM CEST Arnd Bergmann wrote:
> On Monday, September 12, 2016 12:06:25 PM CEST Rob Herring wrote:
> > On Mon, Sep 05, 2016 at 10:07:26PM +0100, Jamie Lentin wrote:
> > > This is a router based on the mv88f5181 chipset.
> > >
> > > http://www.netgear.com/support/product/WNR854T.aspx
> > > http://wiki.openwrt.org/toh/netgear/wnr854t
> > >
> > > Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
> > > ---
> > > This removes the contentious vendor partitioning scheme and goes back
> > > to the original partitioning scheme used in non-DT ports to this board.
> > > Using the same partitioning scheme should mean less surprises for
> > > someone trying to upgrade their router.
> > >
> > > The non-DT PCI setup is still here, as there are other orion5x DT boards
> > > doing very similar things, and can all be converted at the same time.
> >
> > If we keep accepting this duplicated, legacy PCI setup, who is going to
> > be motivated to clean things up. But it's ultimately up to Arnd and
> > Olof.
> >
>
> I mentioned before that I'm feeling a bit uneasy about this too.
>
> Maybe we can instead leave out the PCI support from the new
> file for now and not delete the legacy board file?
>
Another idea that has worked in the past is that we ask everyone
to do one piece of the puzzle. In this case that could be to
convert the existing PCI support to a proper host driver
in arch/arm/mach-orion5x/pci.c that is separate from the PCIe
support (for which we already have a driver IIRC) and have
it probed by calling pci_scan_root_bus() from a platform
driver init function. The next person who wants DT suppor for
an existing orion machine can then add DT support to that driver.
Arnd
^ permalink raw reply
* [PATCH 6/8 v2] arm: orion5x: Add DT-based support for Netgear WNR854T
From: Arnd Bergmann @ 2016-09-12 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912170625.GA7420@rob-hp-laptop>
On Monday, September 12, 2016 12:06:25 PM CEST Rob Herring wrote:
> On Mon, Sep 05, 2016 at 10:07:26PM +0100, Jamie Lentin wrote:
> > This is a router based on the mv88f5181 chipset.
> >
> > http://www.netgear.com/support/product/WNR854T.aspx
> > http://wiki.openwrt.org/toh/netgear/wnr854t
> >
> > Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
> > ---
> > This removes the contentious vendor partitioning scheme and goes back
> > to the original partitioning scheme used in non-DT ports to this board.
> > Using the same partitioning scheme should mean less surprises for
> > someone trying to upgrade their router.
> >
> > The non-DT PCI setup is still here, as there are other orion5x DT boards
> > doing very similar things, and can all be converted at the same time.
>
> If we keep accepting this duplicated, legacy PCI setup, who is going to
> be motivated to clean things up. But it's ultimately up to Arnd and
> Olof.
>
I mentioned before that I'm feeling a bit uneasy about this too.
Maybe we can instead leave out the PCI support from the new
file for now and not delete the legacy board file?
Arnd
^ permalink raw reply
* [PATCHv6 0/3] pwm: imx: support output polarity inversion
From: Clemens Gruber @ 2016-09-12 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912200021.fsnfdgnng4it354g@pengutronix.de>
Hi Uwe,
On Mon, Sep 12, 2016 at 10:00:21PM +0200, Uwe Kleine-K?nig wrote:
> I want that the pwm driver disables its clock on pwm_config(mypwm, 0,
> someperiod) such that the consumer doesn't need to call
> pwm_disable(mypwm) to save power (assuming it's safe to do so, which
> only the pwm provider knows).
I am not sure if this is such a good idea, because there are use cases
where you want to keep the PWM driver enabled the whole time but still
be able to change the duty cycle to 0 for some time without adding
unnecessary delays when changing the duty cycle back to something else.
We have an application where we control fluid valves in a beer
dispensing system through PWMs and these valves are pulsed with
different PWM duty cycles for a short time. In-between the duty cycle
is also 0. For example: Start at 0%, 100ms 90%, 200ms 70%, 300ms 0%,
100ms 90%, and so on..
There it is critical that the change from and to 0 duty cycle is not
delayed by disabling and reenabling the clock.
The oscillator (if there is one) should be up and running, only the duty
cycle should be 0 for a short time.
This would not be possible anymore with your API change, right?
Regards,
Clemens
^ permalink raw reply
* [PATCH 4/8] arm: orion5x: Alias uart0 to serial0 for all orion5x
From: Arnd Bergmann @ 2016-09-12 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472203264-21089-5-git-send-email-jm@lentin.co.uk>
On Friday, August 26, 2016 10:21:00 AM CEST Jamie Lentin wrote:
> diff --git a/arch/arm/boot/dts/orion5x.dtsi b/arch/arm/boot/dts/orion5x.dtsi
> index fbccfbb..001613d 100644
> --- a/arch/arm/boot/dts/orion5x.dtsi
> +++ b/arch/arm/boot/dts/orion5x.dtsi
> @@ -17,6 +17,7 @@
>
> aliases {
> gpio0 = &gpio0;
> + serial0 = &uart0;
> };
>
>
Please put the alias for the serial port in the board specific .dts file,
it's possible that some boards have more than one uart in use,
and that they don't label them the same way as the SoC internal numbering.
Arnd
^ permalink raw reply
* [PATCH v2 1/2] Documentation: dt: add bindings for ti-cpufreq
From: Dave Gerlach @ 2016-09-12 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908033557.GQ27345@vireshk-i7>
Rob,
On 09/07/2016 10:35 PM, Viresh Kumar wrote:
> On 07-09-16, 09:36, Dave Gerlach wrote:
>> On 09/07/2016 12:12 AM, Viresh Kumar wrote:
>>> On 31-08-16, 21:53, Dave Gerlach wrote:
>>>> +In 'operating-points-v2' table:
>>>> +- compatible: Should be
>>>> + - 'operating-points-v2-ti-am3352-cpu' for am335x SoCs
>>>> + - 'operating-points-v2-ti-am4372-cpu' for am43xx SoCs
>>>> + - 'operating-points-v2-ti-dra7-cpu' for dra7xx/am57xx SoCs
>>>
>>> Why do you need SoC specific compatible here? Are you defining new
>>> fields in OPP tables for your SoC ? How are the tables for your case
>>> going to differ from the ones using "operating-points-v2" compatible
>>> string?
>>>
>>
>> I thought you had suggested that I do this in your comments from v1, but I
>> guess that was dependent on whether or not I put the properties I have
>> inserted into the cpu node into the operating-points table instead.
>
> Yes.
>
>> I still
>> have gotten no comments from any DT maintainers so I left it as is. I am
>> still not sure if that is acceptable.
>
> @Rob: Can you please share your views on the new properties being
> added to the CPU node ?
>
I am fine moving the properties in the operating-points-v2 node or
leaving it as is, whichever is preferred.
Viresh, thanks for your comments.
Regards,
Dave
^ permalink raw reply
* [PATCH] Revert "Input: bma150 - extend chip detection for bma180"
From: H. Nikolaus Schaller @ 2016-09-12 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c3312699-4821-7311-0540-3c02c806dde7@redhat.com>
Hi,
> Am 12.09.2016 um 20:52 schrieb Hans de Goede <hdegoede@redhat.com>:
>
> HI,
>
> On 12-09-16 19:20, H. Nikolaus Schaller wrote:
>> Hi,
>>
>>> Am 12.09.2016 um 16:44 schrieb Hans de Goede <hdegoede@redhat.com>:
>>>
>>> Hi,
>>>
>>> On 12-09-16 16:31, H. Nikolaus Schaller wrote:
>>>> Hi,
>>>>
>>>>> Am 11.09.2016 um 18:43 schrieb Hans de Goede <hdegoede@redhat.com>:
>>>>>
>>>>> This reverts commit ef3714fdbc8d ("Input: bma150 - extend chip
>>>>> detection for bma180").
>>>>>
>>>>> The bma180 is not compatible with the bma150 at all, it has 14 bits
>>>>> resolution instead of 10, and it has quite different control registers.
>>>>>
>>>>> Treating the bma180 as a bma150 wrt its data registers will just result
>>>>> in throwing away the lowest 4 bits, which is not too bad. But the ctrl
>>>>> registers are a different story.
>>>>>
>>>>> It may be that things happen to just work (I don't have a bma180 to
>>>>> test with) but that certainly does not make this right.
>>>>
>>>> Yes, looks as if your observation is right. Thanks for pointing this out!
>>>>
>>>> This did need me some research to find an answer...
>>>>
>>>> If I remember correctly, the original patch was based on a recommendation
>>>> from someone I don't remember, who said that the chips are the same in a
>>>> different package. So we added the chip_id and it worked immediately as
>>>> expected. It looks as if we did not check the data sheets. So we did not
>>>> question this recommendation.
>>>>
>>>>>
>>>>> Removing the bma180 id also removes overlap wrt the ids in the iio
>>>>> bma180 driver which does treat the bma180 properly.
>>>>
>>>> Nack.
>>>>
>>>> The problem we get is that an iio driver is not an input driver and can't
>>>> easily replace it.
>>>
>>> Actually almost all accelerometer drivers in the Linux kernel are
>>> iio drivers,
>>
>> Yes, that is a good move indeed to make them more general.
>>
>>> the bma150 driver is the odd duck out,
>>
>> Indeed it seems to be in /misc for some reason.
>>
>>> that is why
>>> we've iio-sensor-proxy for apps which want the accelerometer
>>> to behave as an input device:
>>>
>>> https://github.com/hadess/iio-sensor-proxy
>>
>> Does this provide an input device /dev/input/event?
>> From a first look it seems to provide a D-Bus abstraction which is
>> not the same as an /dev/input/event.
>
> It also provides a /dev/input/event node through uinput:
>
> https://github.com/hadess/iio-sensor-proxy/blob/master/src/fake-input-accelerometer.c
Ah, I didn't see.
>
>
>> What about latency?
>> A kernel driver can react on a sensor interrupt, queue results
>> and sleep.
>>
>> Isn't a user-space process more resource hungry than a kernel thread?
>>
>>>
>>>> An input driver can be used for gesture applications (e.g. detecting
>>>> the device has been turned upside down) and can report X/Y/Z coordinates
>>>> to e.g. X11 for games similar to a mouse or joystick (which the iio driver
>>>> doesn't).
>>>
>>> See above.
>>>
>>>> So it should remain configurable which of both driver options is loaded,
>>>> to match user space API needs.
>>>>
>>>> BTW: id overlap is only a problem if both drivers are configured in parallel.
>>>
>>> Right, so it is "only" a problem to any generic distro which tries to
>>> support both bma150 and bma250 accelerometers, as both the input
>>> bma150 as well as the iio bma250 driver claim to be bma180 compatible.
>>
>> Well, it is only a problem if such a generic distro is really run on a device
>> which has a bma180 defined in DT. There do not seem to exist many of these.
>
> True, still the bma180 compatible is simply just wrong here, and as such
> it really should be removed (it really should never have been added).
Yes, I agree that the patch should be reverted because it is wrong. After we find
a solution for the existing devices.
>
>>>> Next, I have tried to find out which devices really use the bma150 and bma180.
>>>>
>>>> It appears that no in-tree device uses the bma150 while the GTA04 uses
>>>> the bma180 (in DT), but not in any defconfig (the GTA04 specific config
>>>> is not upstreamable since omap2plus_defconfig exists).
>>>>
>>>> In user-space the GTA04 requires and actively uses this input driver for Replicant.
>>>>
>>>> So I would conclude that this revert does not improve/fix any device using a
>>>> bma150 (if it exists at all), but breaks an existing device.
>>>>
>>>> What options do we have?
>>>>
>>>> a) add proper register number constants and choose conditionally (where they differ)
>>>> b) drop bma150 support completely and change registers for bma180
>>>> c) clone the bma150 input driver into an bma180 input driver and fix registers
>>>> d) extend the bma180 iio driver to optionally provide an input device
>>>> e) write a generic input/iio-accel wrapper (which should work with any iio accelerometer)
>>>>
>>>> I would favour approach e)
>>>
>>> Good, because that solution already exists :) See:
>>> https://github.com/hadess/iio-sensor-proxy
>>
>> No, it is yet another option. I would formulate it as:
>>
>> f) break user-space compatibility for existing systems and write / require
>> a user-space workaround.
>>
>> This is something which is the least favorite in my view.
>
> I'm pretty sure that no-one, really no-one wants to do
> evdev emulation for iio devices in the kernel; and there
> is nothing wrong with doing it in userspace.
Yes, there is something wrong. It needs to update the user-space in
a way we can't control and has worse performance.
>
>> Since we have no control over the user space people have installed and IMHO
>> a kernel shouldn't break APIs too often or only for really good reasons
>> (e.g. completely new functions).
>>
>> And we have no means to force user-space developers to integrate such daemons :(
>>
>> So we break a device by upgrading to 4.9-kernel but can't give a solution.
>
> The only user of this seems to be the gta04, and I believe gta04 users
> will not just jump to 4.9 without getting that through some sort
> of central distribution point which can make sure userland gets
> fixed first.
Unfortunatley this assumption is completely wrong. Kernels for gta04 can be
updated independently of user-spaces and therefore they should try not to break
user-space code. This is not always achievable but we try our best.
We provide kernels and people can just install them:
http://download.goldelico.com/letux-kernel/
>
>>>> but it has an issue I have no solution for:
>>>>
>>>> how to define in DT (or CONFIG?) which iio accelerometer(s) should
>>>> be wrapped and presented as input device(s).
>>>
>>> I believe currently iio-sensor-proxy simply wraps all accelerometers
>>> it can find, which seems the right thing to do. Usually we're running
>>> a generic desktop-ish OS / distro which wants these devices
>>> to be available as input devices;
>>> for special cases like actual
>>> robots and stuff running Linux, iio-sensor-proxy can simply be
>>> disabled; or not installed at all.
>>
>> Well, the GTA04 we talk about falls into a third category: a mobile device.
>>
>> Which is not running a desktop-ish OS / distro. It is running Replicant,
>
> For replicant there is:
>
> https://github.com/01org/android-iio-sensors-hal
I don't know if this is part of the Replicant tree or has been integrated. The
most current replicant is Android 4.2.
Things may change with Replicant 6.0 which is still in its infancy and hasn't
been tested on a gta04 at all.
>
>> QtMoko, SHR, FSO or other user spaces which partially rely on /dev/input/event
>> without starting a daemon.
>
> So either these have a gta04 specific version, which can then
> be fixed in parallel with the kernel, like one would do
> with normal distros in a case like this. Or these are generic
> in which case having them work with iio accelerometers is
> a good thing in general, and they may even already work.
>
>> At least in current releases and we have little
>> influence to have them use a new daemon.
>>
>> So I would strongly prefer if we can solve this in the kernel and keep the
>> user-space API for the bma180 input driver stable.
>>
>>>
>>> So all in all I believe that this is a solved problem, since
>>> solution e. from above is already implemented.
>>
>> Well it is also solved if we do not revert the patch at all, because it
>> works in practice (even if not exactly correct) and is compatible to
>> existing user-space.
>>
>> In summary I don't like option f) because it creates more problems than
>> it solves.
>>
>> If e) is ruled out, IMHO the second best option seems to be d) to add a
>> CONFIG_BMA180_INPUT_DEVICE and make it present some additional /dev/input/event
>> in parallel to the iio interface.
>
> Ugh, no we don't need more hacks here. I would greatly prefer to
> just keep the "bma180" is in the bma150 input driver over adding
> evdev event generation to iio drivers (either at the driver level
> or the core).
>
> I think that the best solution might be to do do something like this
> in drivers/input/misc/bma150.c
>
> static const struct i2c_device_id bma150_id[] = {
> { "bma150", 0 },
> #ifndef CONFIG_BMA180 /* Avoid conflict with iio bma180 driver */
> { "bma180", 0 },
> #endif
> { "smb380", 0 },
> { "bma023", 0 },
> { }
> };
>
> Then people relying on this can keep using it, and iio user
> do not have to worry about it.
Oh, that is an interesting compromise.
I don't see anything wrong with it (except that it does not really solve
the fundamental bma180 register issue but that seems to be only a problem
for the gta04 device where it is proven by practice to be no problem).
So if nobody else complains, we should go this way.
BR and thanks,
Nikolaus
>
> Regards,
>
> Hans
>
>
>
>> I already have a similar approach in my to-be-upstreamed queue for the tsc2007
>> touch screen driver to provide additional iio channels for raw values, chip
>> temperature and the auxiliary general purpose ADC (which is used as ambient
>> light sensor in the GTA04).
>>
>> So let's develop some patch for drivers/iio/accel/bma180.c before we revert
>> this bma150 patch and have nothing.
>>
>> BR,
>> Nikolaus Schaller
>>
>>>
>>> Regards,
>>>
>>> Hans
>>>
>>>
>>>
>>>>
>>>> Well, it could be as simple as defining a virtual "input-iio-accel" wrapper
>>>> driver with no real hardware behind and provide a reference to the iio DT node.
>>>> But I think such virtual devices are against DT style.
>>>>
>>>> So I don't know how to implement it in an acceptable way.
>>>>
>>>> Ideas?
>>>>
>>>> BR and thanks,
>>>> Nikolaus Schaller
>>>>
>>>>>
>>>>> Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
>>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>>> ---
>>>>> drivers/input/misc/bma150.c | 4 +---
>>>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/input/misc/bma150.c b/drivers/input/misc/bma150.c
>>>>> index b0d4453..cae4832 100644
>>>>> --- a/drivers/input/misc/bma150.c
>>>>> +++ b/drivers/input/misc/bma150.c
>>>>> @@ -70,7 +70,6 @@
>>>>> #define BMA150_CFG_5_REG 0x11
>>>>>
>>>>> #define BMA150_CHIP_ID 2
>>>>> -#define BMA180_CHIP_ID 3
>>>>> #define BMA150_CHIP_ID_REG BMA150_DATA_0_REG
>>>>>
>>>>> #define BMA150_ACC_X_LSB_REG BMA150_DATA_2_REG
>>>>> @@ -539,7 +538,7 @@ static int bma150_probe(struct i2c_client *client,
>>>>> }
>>>>>
>>>>> chip_id = i2c_smbus_read_byte_data(client, BMA150_CHIP_ID_REG);
>>>>> - if (chip_id != BMA150_CHIP_ID && chip_id != BMA180_CHIP_ID) {
>>>>> + if (chip_id != BMA150_CHIP_ID) {
>>>>> dev_err(&client->dev, "BMA150 chip id error: %d\n", chip_id);
>>>>> return -EINVAL;
>>>>> }
>>>>> @@ -643,7 +642,6 @@ static UNIVERSAL_DEV_PM_OPS(bma150_pm, bma150_suspend, bma150_resume, NULL);
>>>>>
>>>>> static const struct i2c_device_id bma150_id[] = {
>>>>> { "bma150", 0 },
>>>>> - { "bma180", 0 },
>>>>> { "smb380", 0 },
>>>>> { "bma023", 0 },
>>>>> { }
>>>>> --
>>>>> 2.9.3
>>>>>
>>>>
>>
^ permalink raw reply
* [RFC PATCH 9/9] ethernet: sun8i-emac: add pm_runtime support
From: Maxime Ripard @ 2016-09-12 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473425117-18645-10-git-send-email-clabbe.montjoie@gmail.com>
Hi,
On Fri, Sep 09, 2016 at 02:45:17PM +0200, Corentin Labbe wrote:
> This patch add pm_runtime support to sun8i-emac.
> For the moment, only basic support is added, (the device is marked as
> used when net/open)
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> drivers/net/ethernet/allwinner/sun8i-emac.c | 62 ++++++++++++++++++++++++++++-
> 1 file changed, 60 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/allwinner/sun8i-emac.c b/drivers/net/ethernet/allwinner/sun8i-emac.c
> index 1c4bc80..cce886e 100644
> --- a/drivers/net/ethernet/allwinner/sun8i-emac.c
> +++ b/drivers/net/ethernet/allwinner/sun8i-emac.c
> @@ -9,7 +9,6 @@
> * - MAC filtering
> * - Jumbo frame
> * - features rx-all (NETIF_F_RXALL_BIT)
> - * - PM runtime
> */
> #include <linux/bitops.h>
> #include <linux/clk.h>
> @@ -27,6 +26,7 @@
> #include <linux/pinctrl/consumer.h>
> #include <linux/pinctrl/pinctrl.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> #include <linux/reset.h>
> #include <linux/scatterlist.h>
> #include <linux/skbuff.h>
> @@ -1301,11 +1301,18 @@ static int sun8i_emac_open(struct net_device *ndev)
> int err;
> u32 v;
>
> + err = pm_runtime_get_sync(priv->dev);
> + if (err) {
> + pm_runtime_put_noidle(priv->dev);
> + dev_err(priv->dev, "pm_runtime error: %d\n", err);
> + return err;
> + }
> +
> err = request_irq(priv->irq, sun8i_emac_dma_interrupt, 0,
> dev_name(priv->dev), ndev);
> if (err) {
> dev_err(priv->dev, "Cannot request IRQ: %d\n", err);
> - return err;
> + goto err_runtime;
> }
>
> /* Set interface mode (and configure internal PHY on H3) */
> @@ -1395,6 +1402,8 @@ err_syscon:
> sun8i_emac_unset_syscon(ndev);
> err_irq:
> free_irq(priv->irq, ndev);
> +err_runtime:
> + pm_runtime_put(priv->dev);
> return err;
> }
>
> @@ -1483,6 +1492,8 @@ static int sun8i_emac_stop(struct net_device *ndev)
> dma_free_coherent(priv->dev, priv->nbdesc_tx * sizeof(struct dma_desc),
> priv->dd_tx, priv->dd_tx_phy);
>
> + pm_runtime_put(priv->dev);
> +
> return 0;
> }
>
> @@ -2210,6 +2221,8 @@ static int sun8i_emac_probe(struct platform_device *pdev)
> goto probe_err;
> }
>
> + pm_runtime_enable(priv->dev);
> +
> return 0;
>
> probe_err:
> @@ -2221,6 +2234,8 @@ static int sun8i_emac_remove(struct platform_device *pdev)
> {
> struct net_device *ndev = platform_get_drvdata(pdev);
>
> + pm_runtime_disable(&pdev->dev);
> +
> unregister_netdev(ndev);
> platform_set_drvdata(pdev, NULL);
> free_netdev(ndev);
> @@ -2228,6 +2243,47 @@ static int sun8i_emac_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static int __maybe_unused sun8i_emac_suspend(struct platform_device *pdev, pm_message_t state)
> +{
> + struct net_device *ndev = platform_get_drvdata(pdev);
> + struct sun8i_emac_priv *priv = netdev_priv(ndev);
> +
> + napi_disable(&priv->napi);
> +
> + if (netif_running(ndev))
> + netif_device_detach(ndev);
> +
> + sun8i_emac_stop_tx(ndev);
> + sun8i_emac_stop_rx(ndev);
> +
> + sun8i_emac_rx_clean(ndev);
> + sun8i_emac_tx_clean(ndev);
> +
> + phy_stop(ndev->phydev);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused sun8i_emac_resume(struct platform_device *pdev)
> +{
> + struct net_device *ndev = platform_get_drvdata(pdev);
> + struct sun8i_emac_priv *priv = netdev_priv(ndev);
> +
> + phy_start(ndev->phydev);
> +
> + sun8i_emac_start_tx(ndev);
> + sun8i_emac_start_rx(ndev);
> +
> + if (netif_running(ndev))
> + netif_device_attach(ndev);
> +
> + netif_start_queue(ndev);
> +
> + napi_enable(&priv->napi);
> +
> + return 0;
> +}
The main idea behind the runtime PM hooks is that they bring the
device to a working state and shuts it down when it's not needed
anymore.
However, they shouldn't be called when the device is still in used, so
all the mangling with NAPI, the phy and so on is irrelevant here, but
the clocks, resets, for example, are.
> static const struct of_device_id sun8i_emac_of_match_table[] = {
> { .compatible = "allwinner,sun8i-a83t-emac",
> .data = &emac_variant_a83t },
> @@ -2246,6 +2302,8 @@ static struct platform_driver sun8i_emac_driver = {
> .name = "sun8i-emac",
> .of_match_table = sun8i_emac_of_match_table,
> },
> + .suspend = sun8i_emac_suspend,
> + .resume = sun8i_emac_resume,
These are not the runtime PM hooks. How did you test that?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160912/33d774be/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] ARM64: dts: amlogic: Add basic support for Amlogic S905X
From: Kevin Hilman @ 2016-09-12 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOQ7t2bWLq2XP2rKx3msf=1tUfXkQuBWagun46TaKk73qXr=FQ@mail.gmail.com>
Carlo Caione <carlo@caione.org> writes:
> On Mon, Sep 12, 2016 at 6:28 PM, Andreas F?rber <afaerber@suse.de> wrote:
>
>>> +Boards with the Amlogic Meson GXL SoC shall have the following properties:
>>> + Required root node property:
>>> + compatible: "amlogic,meson-gxl-s905x", "amlogic,meson-gxl";
>>
>> Can we please use "amlogic,s905x", "amlogic,meson-gxl"? No need to
>> complicate the name. Also affects .dtsi and .dts below.
>
> gxl != s905x.
>
> AFAWK to the GXL family belong several different SoCs, like S905X,
> S905D, etc... (see patch 3/3)
> This is why we use meson-gxl-s905x, meson-gxl-s905d, etc...
Correct.
> We could s/meson-gxl-s905x/meson-s905x/ and
> s/meson-gxl-s905d/meson-s905d/ but I honestly prefer this way because
> we can clearly see which family the SoC belongs to (the Amlogic naming
> convention is already messy enough).
> I mean, yes it's longer, but it's for the sake of documentation IMO.
+1
Kevin
^ permalink raw reply
* [PATCH v2 0/4] ARM: amlogic: Add spifc support to Amlogic's GXBB family
From: Kevin Hilman @ 2016-09-12 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473409738-27175-1-git-send-email-jbrunet@baylibre.com>
Jerome Brunet <jbrunet@baylibre.com> writes:
> This patch series adds the necessary pins, clocks and device tree nodes to
> enable the spifc controller on the GXBB family. I had to add the nand pins
> in pintctrl as the pinmux setting left by u-boot was conflicting with the
> spifc pinmux during my test on the P200.
This series seems to be missing a patch which enables the SPIfc on the
P200 board for use with the on-board NOR flash.
Kevin
> Changes since v1 at : http://lkml.kernel.org/r/1473261223-15412-1-git-send-email-jbrunet at baylibre.com
> * Omit patches :
> - dt-bindings: spi-meson: Add GXBB Compatible string
> - spi: meson: Add GXBB compatible
> Sent as dedicated series
> * Omit patch:
> - clk: gxbb: expose spifc clock
> Already applied
> * Rename SPI flash controller pins from spifc_* to nor_* to keep the
> name aligned with the datasheet
>
> Jerome Brunet (3):
> pinctrl: amlogic: gxbb: add spi nor pins
> pinctrl: amlogic: gxbb: add nand pins
> ARM64: dts: amlogic: add spi nor pins
>
> Neil Armstrong (1):
> ARM64: dts: meson-gxbb: Add SPIFC node
>
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 19 +++++++++++++++
> drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 37 +++++++++++++++++++++++++++++
> 2 files changed, 56 insertions(+)
^ permalink raw reply
* [GIT PULL] CLCD graphics for the Nomadik NHK15
From: Linus Walleij @ 2016-09-12 20:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC folks,
this adds CLCD graphics to the Nomadik NHK15 following
Tomi's merge of the required FBDEV changes.
It is all device tree changes except for a oneliner selecting
MFD_SYSCON from the Nomadik Kconfig, as there are
no other Nomadik changes pending and nothing else
should be changing the Nomadik, and since it is pretty
much in context with the DTS changes, I chose to include
it here.
Please pull it in!
Yours,
Linus Walleij
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
tags/clcd-nomadik
for you to fetch changes up to 17470b7da11c137267c74ff0d2d4cca56f595c60:
ARM: dts: add the CLCD LCD display to the NHK15 (2016-09-09 23:16:07 +0200)
----------------------------------------------------------------
CLCD graphics on the Nomadik NHK15
----------------------------------------------------------------
Linus Walleij (6):
ARM: dts: add STMPE PWM to the NHK15 device tree
dt-bindings: add vendor TPO
dt-bindings: Add TPO TPG110 binding
ARM: nomadik: select MFD_SYSCON
ARM: dts: add PMU to the NHK15 device tree
ARM: dts: add the CLCD LCD display to the NHK15
.../bindings/display/panel/tpo,tpg110.txt | 47 +++++++++++++++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/ste-nomadik-nhk15.dts | 68 ++++++++++++++++++++++
arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 28 +++++++++
arch/arm/mach-nomadik/Kconfig | 1 +
5 files changed, 145 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
^ permalink raw reply
* [PATCH 1/3] misc: Add Aspeed BT IPMI host driver
From: Corey Minyard @ 2016-09-12 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4727554.yt7pF8chOH@wuerfel>
On 09/12/2016 02:15 PM, Arnd Bergmann wrote:
> On Monday, September 12, 2016 1:55:40 PM CEST Corey Minyard wrote:
>> On 09/02/2016 08:22 AM, C?dric Le Goater wrote:
>>> Hello,
>>>
>>> Adding Corey in cc: . I guess I should have done that in the first place.
>> Yes, probably so. I've been travelling and didn't see it on the mailing
>> lists until now.
>>
>> There is already a BT driver in the kernel, in drivers/char/ipmi, why
>> won't that work?
> The new driver is the host side (running on the BMC), the existing one
> is the client (running on the PC).
>
> Arnd
Ok, that's not really clear from the documentation or the Kconfig.
In the IPMI spec the "host" side is the computer side, not the BMC
side. Like:
11.6.1 BT Host Interface Registers
The Host BT interface provides an independent set of registers and
interrupts to allow the Host driver to
communicate with the baseboard management controller without
conflicting with the O/S ACPI driver.
In light of that, this should probably be named the bt-bmc driver.
I haven't reviewed this in detail, but I'm ok with putting it in
drivers/char/ipmi. The state machine part looks reasonably
generic. The configuration part isn't, but that could be split
out later if necessary.
The biggest thing I don't like is the byte at a time interfaces
from userspace. That seems fairly inefficient if the system
does extra work for each userspace access. IIRC some
systems do and some don't.
-corey
>
> _______________________________________________
> 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 v2 3/4] ARM: dts: imx23: Fix build warnings with W=1
From: Stefan Wahren @ 2016-09-12 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473103670-15922-3-git-send-email-festevam@gmail.com>
> Fabio Estevam <festevam@gmail.com> hat am 5. September 2016 um 21:27
> geschrieben:
>
>
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Fix the following build warnings with W=1:
>
> Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but
> no unit name
>
> While at it, also pass the 'device_type' property as recommended by the
> ePAPR specification.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Patch 1 and 3 works for my Olinuxino board.
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
^ permalink raw reply
* [PATCHv6 0/3] pwm: imx: support output polarity inversion
From: Uwe Kleine-König @ 2016-09-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <074eed0df23199bc82f8d221690596d3@agner.ch>
Hello Stefan,
On Mon, Sep 12, 2016 at 09:51:26AM -0700, Stefan Agner wrote:
> On 2016-09-12 07:04, Uwe Kleine-K?nig wrote:
> > Hello,
> >
> > On Mon, Sep 12, 2016 at 02:45:53PM +0200, Alexandre Belloni wrote:
> >> Isn't a properly designed PWM putting a high level on its pin when
> >> disabled and configured with inversed polarity ?
> >
> > it's not well defined. When trying several times over the years to
> > properly define and document it, I didn't manage to agree with Thierry
> > what is the right thing to define.
> >
> > IMHO it would be sensible to make it explicitly undefined what happens
> > when a PMW is disabled. This would simplify drivers from
> >
> > pwm_config(mypwm, value, period);
> > if (!value)
> > pwm_disable(mypwm)
> > else
> > pwm_enable(led_dat->pwm);
> >
> > to
> >
> > pwm_config(mypwm, value, period);
> >
> > and let the pwm driver disable it's clock (or whatever) when value is 0
> > and there are energy saving benefits that don't hurt the expected
> > behaviour of the pin. So the hardware specific stuff is handled in the
> > hardware specific driver and usage in pwm-consumers is simplified.
> > Moreover this also simplifies some pwm drivers because they don't have
> > to catch in software the cases where the hardware differs from the
> > expectation[1].
>
> That sounds like a sane definition to me and what I would have expected
> from the PWM framework. That the pin is not defined after pwm_disable is
> totally understandable. It is usually a case which the board designer
> anyway needs to take care of (e.g. what is the state right after power
> on? If the designer cares about, he will put a pull-up/down in place).
>
> And it seems also Sascha suggested that:
> https://lkml.org/lkml/2013/1/4/139
actually I talked to Sascha in private before ranting :-)
> I did not found where Thierry disagreed to that...?
Hmm, I used gmane links before, most of them are dead today. :-|
http://www.spinics.net/lists/linux-leds/msg03237.html is one example.
> > Today it's a (maybe small) bug, when a pwm consumer calls pwm_config with
> > value=0 and doesn't disable it afterwards. IMHO that's a bug in the pwm
> > API that pwm_config with value=0 doesn't imply (the wanted effects of)
> > pwm_disable.
>
> I don't quite get what you are saying here. What wanted effects of
> pwm_disable would you like to move into pwm_config with value=0?
I want that the pwm driver disables its clock on pwm_config(mypwm, 0,
someperiod) such that the consumer doesn't need to call
pwm_disable(mypwm) to save power (assuming it's safe to do so, which
only the pwm provider knows).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 00/17] Make rpmsg a framework
From: Bjorn Andersson @ 2016-09-12 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7682a26a-310b-b283-dfe8-56d114f92dcb@codeaurora.org>
On Mon 12 Sep 12:21 PDT 2016, Jeffrey Hugo wrote:
> On 9/12/2016 12:49 PM, Bjorn Andersson wrote:
> >On Mon 12 Sep 11:13 PDT 2016, Jeffrey Hugo wrote:
> >
> >>On 9/12/2016 12:00 PM, Bjorn Andersson wrote:
[..]
> >>>Can you point me to the downstream code where this is implemented so I
> >>>can have a look? Do you expect to get the response on that request?
> >>
> >>Have a look at -
> >>smd_mask_receive_interrupt()
> >>smd_is_pkt_avail()
> >>
> >
> >In msm-3.18 these still seems to only come from either
> >msm_rpm_enter_sleep() and the rpm-clock driver, related to flushing
> >cached sleep state requests.
> >
> >>Every request to the RPM generates a response. The Linux RPM driver may
> >>decide to let the response sit in the fifo, or it may need to read and
> >>process it.
> >>
> >
> >Right, I presume we save some time by not waiting for these responses as
> >we want to reach sleep as soon as possible. The answer I got last time
> >this was discussed was that it was an optimization, not a functional
> >requirement.
>
> Two optimizations in play here.
>
> First, disabling interrupts prevents an immediate wakeup. When the system
> is entering sleep, IRQs are disabled. The sleep request to RPM will trigger
> a response, and the IRQ for that response will be queued. Once the sleep
> processing is done, IRQs get enabled, so the pending IRQ from RPM will cause
> an immediate wakeup. The system will process the wakeup, and then go back
> to sleep (sans request because nothing has changed). This down-up-down
> processing burns a lot of power.
>
But which "sleep request" is this? The only one I can find is the
flushing of sleep state values from the rpm resource tables.
> Second is not waiting for the response. Linux doesn't really do anything
> with the sleep request response, so we can enter sleep faster by not waiting
> for the response and processing (discarding) it when the system wakes up as
> scheduled.
Right, as long as the RPM code doesn't consider it a timeout don't have
a problem if those ack's are handled after the resume.
> However, Linux needs to ensure there is enough fifo space to
> hold that response while asleep, otherwise the RPM will panic and crash the
> system. Therefore, if there are a number of outstanding requests that would
> fill the fifo, then the RPM driver on Linux needs to spin and drain requests
> from the fifo until a minimum free space buffer to hold additional expected
> pending responses is established. This has to occur with IRQs disabled.
>
Right. Which means that the RPM driver needs to know how large the rx
fifo is, what overhead the underlaying transport mechanism has and then
calculate how many responses it should leave room for.
[..]
> >>If I recall correctly, there was a parameter in the RPM driver
> >>for the transmit function that indicated if the request was being made in
> >>atomic context or not, which would change the behavior of how the transmit
> >>was handled.
> >>
> >
> >You're correct, the question is still which of these code paths are
> >actually needed and to motivate the endless maintenance of the extra
> >code.
>
> If we are just talking about transmitting in atomic context (not necessarily
> related to sleep), if I recall correctly, some bus requests are sent to RPM
> in atomic context, some APR requests to the Audio DSP are done in atomic
> context, and I think IPC Router uses atomic context in some cases. As a
> generic framework that should support usecases to all processors/subsystems,
> I don't think transmitting in atomic context is a special case for
> RPM/sleep.
>
I have not looked through all of APR yet and don't know where msm_bus is
heading, but for IPC-router your correct that the downstream driver does
indeed require this; but that's a side effect of the downstream
ipcrouter implementation, not the problem itself.
Regards,
Bjorn
^ permalink raw reply
* [PATCH] arm64: defconfig: enable meson SPI as module
From: Kevin Hilman @ 2016-09-12 19:43 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 2d6576fe6057..17d26e958a3a 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -188,6 +188,7 @@ CONFIG_I2C_UNIPHIER_F=y
CONFIG_I2C_RCAR=y
CONFIG_I2C_CROS_EC_TUNNEL=y
CONFIG_SPI=y
+CONFIG_SPI_MESON_SPIFC=m
CONFIG_SPI_ORION=y
CONFIG_SPI_PL022=y
CONFIG_SPI_QUP=y
--
2.9.3
^ permalink raw reply related
* [UPDATE PATCH V11 1/8] ACPI: I/O Remapping Table (IORT) initial support
From: Marc Zyngier @ 2016-09-12 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87c1d6a4-a760-9f8a-ddbe-7cf6655d575b@semihalf.com>
On Mon, 12 Sep 2016 20:58:42 +0200
Tomasz Nowicki <tn@semihalf.com> wrote:
> On 12.09.2016 20:54, Tomasz Nowicki wrote:
> > IORT shows representation of IO topology for ARM based systems.
> > It describes how various components are connected together on
> > parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec.
> > http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
> >
> > Initial support allows to detect IORT table presence and save its
> > root pointer obtained through acpi_get_table(). The pointer validity
> > depends on acpi_gbl_permanent_mmap because if acpi_gbl_permanent_mmap
> > is not set while using IORT nodes we would dereference unmapped pointers.
> >
> > For the aforementioned reason call acpi_iort_init() from acpi_init()
> > which guarantees acpi_gbl_permanent_mmap to be set at that point.
> >
> > Add generic helpers which are helpful for scanning and retrieving
> > information from IORT table content. List of the most important helpers:
> > - iort_find_dev_node() finds IORT node for a given device
> > - iort_node_map_rid() maps device RID and returns IORT node which provides
> > final translation
> >
> > IORT support is placed under drivers/acpi/arm64/ new directory due to its
> > ARM64 specific nature. The code there is considered only for ARM64.
> > The long term plan is to keep all ARM64 specific tables support
> > in this place e.g. GTDT table.
> >
> > Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> > Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>
> > Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
> > Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>
> Hi Marc,
>
> Series with updated patch 1 can be found:
> https://github.com/semihalf-nowicki-tomasz/linux.git (its-acpi-v11)
>
> Sorry for zillions of patch updates...
I've swapped the two patches and pushed the result out again, but from
now on, please send updates on top of irq/irqchip-4.9.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [PATCH v2] extcon: Add support for qcom SPMI PMIC USB id detection hardware
From: Stephen Boyd @ 2016-09-12 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D60E56.10807@samsung.com>
Quoting Chanwoo Choi (2016-09-11 19:09:26)
> Hi Stephen,
>
> Looks good to me.
> But, there are something that need to be modified.
> - add the author information
> - add the description of driver
> - use the extcon_set_state() instead of extcon_set_cable_state_()
>
> I modified this patch and applied it because I should send
> the pull request within this week after releasing the rc6.
>
> I added the comment about the modification.
>
Ok, sounds good. Thanks.
^ permalink raw reply
* [PATCH v2 00/17] Make rpmsg a framework
From: Jeffrey Hugo @ 2016-09-12 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912184957.GI405@tuxbot>
On 9/12/2016 12:49 PM, Bjorn Andersson wrote:
> On Mon 12 Sep 11:13 PDT 2016, Jeffrey Hugo wrote:
>
>> On 9/12/2016 12:00 PM, Bjorn Andersson wrote:
>>> On Mon 12 Sep 09:52 PDT 2016, Lina Iyer wrote:
>>>
>>>> Hi Bjorn,
>>>>
>>>> On Thu, Sep 01 2016 at 16:28 -0600, Bjorn Andersson wrote:
>>>>> This series splits the virtio rpmsg bus driver into a rpmsg bus and a virtio
>>>>> backend/wireformat.
>>>>>
>>>>>
>>>>> As we discussed the Qualcomm SMD implementation a couple of years back people
>>>>> suggested that I should make it "a rpmsg thingie". With the introduction of the
>>>>> Qualcomm 8996 platform, we must support a variant of the communication
>>>>> mechanism that share many of the characteristics of SMD, but are different
>>>>> enough that it can't be done in a single implementation. As such there is
>>>>> enough benefit to do the necessary work and being able to make SMD a "rpmsg
>>>>> thingie".
>>>>>
>>>>> On-top of this series I have patches to switch the current smd clients over to
>>>>> rpmsg (and by that drop the existing SMD implementation).
>>>>>
>>>>> All this allows me to implement the new backend and reuse all existing SMD
>>>>> drivers with the new mechanism.
>>>>>
>>>>
>>>> RPM Communication has to supported even when IRQs are disabled. The most
>>>> important use of this communication is to set the wake up time for the
>>>> CPU subsystem when all the CPUs are powered off.
>>>
>>> Can you point me to the downstream code where this is implemented so I
>>> can have a look? Do you expect to get the response on that request?
>>
>> Have a look at -
>> smd_mask_receive_interrupt()
>> smd_is_pkt_avail()
>>
>
> In msm-3.18 these still seems to only come from either
> msm_rpm_enter_sleep() and the rpm-clock driver, related to flushing
> cached sleep state requests.
>
>> Every request to the RPM generates a response. The Linux RPM driver may
>> decide to let the response sit in the fifo, or it may need to read and
>> process it.
>>
>
> Right, I presume we save some time by not waiting for these responses as
> we want to reach sleep as soon as possible. The answer I got last time
> this was discussed was that it was an optimization, not a functional
> requirement.
Two optimizations in play here.
First, disabling interrupts prevents an immediate wakeup. When the
system is entering sleep, IRQs are disabled. The sleep request to RPM
will trigger a response, and the IRQ for that response will be queued.
Once the sleep processing is done, IRQs get enabled, so the pending IRQ
from RPM will cause an immediate wakeup. The system will process the
wakeup, and then go back to sleep (sans request because nothing has
changed). This down-up-down processing burns a lot of power.
Second is not waiting for the response. Linux doesn't really do
anything with the sleep request response, so we can enter sleep faster
by not waiting for the response and processing (discarding) it when the
system wakes up as scheduled. However, Linux needs to ensure there is
enough fifo space to hold that response while asleep, otherwise the RPM
will panic and crash the system. Therefore, if there are a number of
outstanding requests that would fill the fifo, then the RPM driver on
Linux needs to spin and drain requests from the fifo until a minimum
free space buffer to hold additional expected pending responses is
established. This has to occur with IRQs disabled.
>
>
> I'm not at all against having the rpm driver cache the state
> information and the smd driver process read/writes from the rpm driver
> in IRQ context. I do however not know how to trigger the flush in a sane
> way.
>
>>>
>>>> In addition to that,
>>>> "sleep" votes that are sent by the application processor subsystem to
>>>> allow system to go into deep sleep modes can only be triggered when the
>>>> CPU PM domains are power collapsed, drivers do not have a knowledge of
>>>> when that happens.
>>>
>>> Do you mean the actual sleep votes can only be with the CPU PM domains
>>> collapsed?
>>>
>>> It's been a while since I dug through that code, but there was several
>>> cases where sleep votes would be sent out during normal execution as
>>> well, and then there's the optimization of flushing out all cached sleep
>>> votes when we're on the way down.
>>>
>>>> This has to be done by a platform code that registers
>>>> for CPU PM domain power_off/on callbacks.
>>>>
>>>
>>> Ok, sounds like we have a legit use case for improving this.
>>>
>>>> Using rpmsg may be nice for RPM SMD communication, but mutexes need to
>>>> go away for this driver to be any useful than bare bones active mode
>>>> resource requests for QCOM SoCs. By not doing that now, we lock
>>>> ourselves out of using this SMD driver in the near future when CPU PM
>>>> domains are available in the kernel with an ability to do system low
>>>> power modes.
>>>>
>>>
>>> The last time I looked at this there where no cases when it was
>>> _required_ to support transmitting requests to the rpm from IRQ context.
>>
>> I no longer work on SMD, but when I did this was in fact a strict
>> requirement.
>
> When I dissected all the users of the API I came to the conclusion that
> this requirement (on the SMD driver) came from above mentioned
> optimization.
>
>> If I recall correctly, there was a parameter in the RPM driver
>> for the transmit function that indicated if the request was being made in
>> atomic context or not, which would change the behavior of how the transmit
>> was handled.
>>
>
> You're correct, the question is still which of these code paths are
> actually needed and to motivate the endless maintenance of the extra
> code.
If we are just talking about transmitting in atomic context (not
necessarily related to sleep), if I recall correctly, some bus requests
are sent to RPM in atomic context, some APR requests to the Audio DSP
are done in atomic context, and I think IPC Router uses atomic context
in some cases. As a generic framework that should support usecases to
all processors/subsystems, I don't think transmitting in atomic context
is a special case for RPM/sleep.
Lina et al would probably know better about the usecase details than I
at this point however.
>
>
> Nice to see you on the mailing list again Jeff.
>
> Regards,
> Bjorn
>
--
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 1/3] misc: Add Aspeed BT IPMI host driver
From: Arnd Bergmann @ 2016-09-12 19:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1ce6c4b4-5938-22fc-7467-d1efc220b772@gmail.com>
On Monday, September 12, 2016 1:55:40 PM CEST Corey Minyard wrote:
> On 09/02/2016 08:22 AM, C?dric Le Goater wrote:
> > Hello,
> >
> > Adding Corey in cc: . I guess I should have done that in the first place.
>
> Yes, probably so. I've been travelling and didn't see it on the mailing
> lists until now.
>
> There is already a BT driver in the kernel, in drivers/char/ipmi, why
> won't that work?
The new driver is the host side (running on the BMC), the existing one
is the client (running on the PC).
Arnd
^ permalink raw reply
* Applied "spi: meson: Add GXBB Compatible string" to the spi tree
From: Mark Brown @ 2016-09-12 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473261223-15412-6-git-send-email-jbrunet@baylibre.com>
The patch
spi: meson: Add GXBB Compatible string
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 164c5cd5ffabfa7a060999f8184927017287c39b Mon Sep 17 00:00:00 2001
From: Neil Armstrong <narmstrong@baylibre.com>
Date: Thu, 8 Sep 2016 09:53:25 +0200
Subject: [PATCH] spi: meson: Add GXBB Compatible string
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Documentation/devicetree/bindings/spi/spi-meson.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/spi-meson.txt b/Documentation/devicetree/bindings/spi/spi-meson.txt
index bb52a86f3365..dc6d0313324a 100644
--- a/Documentation/devicetree/bindings/spi/spi-meson.txt
+++ b/Documentation/devicetree/bindings/spi/spi-meson.txt
@@ -7,7 +7,7 @@ NOR memories, without DMA support and a 64-byte unified transmit /
receive buffer.
Required properties:
- - compatible: should be "amlogic,meson6-spifc"
+ - compatible: should be "amlogic,meson6-spifc" or "amlogic,meson-gxbb-spifc"
- reg: physical base address and length of the controller registers
- clocks: phandle of the input clock for the baud rate generator
- #address-cells: should be 1
--
2.8.1
^ 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