[PATCH v2 3/4] mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem
Nadav reported parallel MADV_DONTNEED on same range has a stale TLB problem and Mel fixed it[1] and found same problem on MADV_FREE[2]. Quote from Mel Gorman "The race in question is CPU 0 running madv_free and updating some PTEs while CPU 1 is also running madv_free and looking at the same PTEs. CPU 1 may have writable TLB entries for a page but fail the pte_dirty check (because CPU 0 has updated it already) and potentially fail to flush. Hence, when madv_free on CPU 1 returns, there are still potentially writable TLB entries and the underlying PTE is still present so that a subsequent write does not necessarily propagate the dirty bit to the underlying PTE any more. Reclaim at some unknown time at the future may then see that the PTE is still clean and discard the page even though a write has happened in the meantime. I think this is possible but I could have missed some protection in madv_free that prevents it happening." This patch aims for solving both problems all at once and is ready for other problem with KSM, MADV_FREE and soft-dirty story[3]. TLB batch API(tlb_[gather|finish]_mmu] uses [inc|dec]_tlb_flush_pending and mmu_tlb_flush_pending so that when tlb_finish_mmu is called, we can catch there are parallel threads going on. In that case, forcefully, flush TLB to prevent for user to access memory via stale TLB entry although it fail to gather page table entry. I confiremd this patch works with [4] test program Nadav gave so this patch supersedes "mm: Always flush VMA ranges affected by zap_page_range v2" in current mmotm. NOTE: This patch modifies arch-specific TLB gathering interface(x86, ia64, s390, sh, um). It seems most of architecture are straightforward but s390 need to be careful because tlb_flush_mmu works only if mm->context.flush_mm is set to non-zero which happens only a pte entry really is cleared by ptep_get_and_clear and friends. However, this problem never changes the pte entries but need to flush to prevent memory access from stale tlb. Any thoughts? [1] http://lkml.kernel.org/r/20170725101230.5v7gvnjmcnkzz...@techsingularity.net [2] http://lkml.kernel.org/r/20170725100722.2dxnmgypmwnrf...@suse.de [3] http://lkml.kernel.org/r/bd3a0ebe-ecf4-41d4-87fa-c755ea9ab...@gmail.com [4] https://patchwork.kernel.org/patch/9861621/ Cc: Ingo MolnarCc: Russell King Cc: Tony Luck Cc: Martin Schwidefsky Cc: "David S. Miller" Cc: Heiko Carstens Cc: Yoshinori Sato Cc: Jeff Dike Cc: linux-a...@vger.kernel.org Cc: Nadav Amit Reported-by: Mel Gorman Signed-off-by: Minchan Kim --- arch/arm/include/asm/tlb.h | 7 ++- arch/ia64/include/asm/tlb.h | 4 +++- arch/s390/include/asm/tlb.h | 7 ++- arch/sh/include/asm/tlb.h | 4 ++-- arch/um/include/asm/tlb.h | 7 ++- include/asm-generic/tlb.h | 2 +- include/linux/mm_types.h| 8 mm/memory.c | 32 +--- 8 files changed, 49 insertions(+), 22 deletions(-) diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h index 7f5b2a2d3861..d5562f9ce600 100644 --- a/arch/arm/include/asm/tlb.h +++ b/arch/arm/include/asm/tlb.h @@ -168,8 +168,13 @@ arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, static inline void arch_tlb_finish_mmu(struct mmu_gather *tlb, - unsigned long start, unsigned long end) + unsigned long start, unsigned long end, bool force) { + if (force) { + tlb->range_start = start; + tlb->range_end = end; + } + tlb_flush_mmu(tlb); /* keep the page table cache within bounds */ diff --git a/arch/ia64/include/asm/tlb.h b/arch/ia64/include/asm/tlb.h index 93cadc04ac62..cbe5ac3699bf 100644 --- a/arch/ia64/include/asm/tlb.h +++ b/arch/ia64/include/asm/tlb.h @@ -187,8 +187,10 @@ arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, */ static inline void arch_tlb_finish_mmu(struct mmu_gather *tlb, - unsigned long start, unsigned long end) + unsigned long start, unsigned long end, bool force) { + if (force) + tlb->need_flush = 1; /* * Note: tlb->nr may be 0 at this point, so we can't rely on tlb->start_addr and * tlb->end_addr. diff --git a/arch/s390/include/asm/tlb.h b/arch/s390/include/asm/tlb.h index fa4b461694b7..3a14b864b2e3 100644 --- a/arch/s390/include/asm/tlb.h +++ b/arch/s390/include/asm/tlb.h @@ -77,8 +77,13 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb) static inline void arch_tlb_finish_mmu(struct mmu_gather *tlb, - unsigned long start, unsigned long end) + unsigned long start, unsigned long end, bool force) { +
[PATCH v2 3/4] mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem
Nadav reported parallel MADV_DONTNEED on same range has a stale TLB problem and Mel fixed it[1] and found same problem on MADV_FREE[2]. Quote from Mel Gorman "The race in question is CPU 0 running madv_free and updating some PTEs while CPU 1 is also running madv_free and looking at the same PTEs. CPU 1 may have writable TLB entries for a page but fail the pte_dirty check (because CPU 0 has updated it already) and potentially fail to flush. Hence, when madv_free on CPU 1 returns, there are still potentially writable TLB entries and the underlying PTE is still present so that a subsequent write does not necessarily propagate the dirty bit to the underlying PTE any more. Reclaim at some unknown time at the future may then see that the PTE is still clean and discard the page even though a write has happened in the meantime. I think this is possible but I could have missed some protection in madv_free that prevents it happening." This patch aims for solving both problems all at once and is ready for other problem with KSM, MADV_FREE and soft-dirty story[3]. TLB batch API(tlb_[gather|finish]_mmu] uses [inc|dec]_tlb_flush_pending and mmu_tlb_flush_pending so that when tlb_finish_mmu is called, we can catch there are parallel threads going on. In that case, forcefully, flush TLB to prevent for user to access memory via stale TLB entry although it fail to gather page table entry. I confiremd this patch works with [4] test program Nadav gave so this patch supersedes "mm: Always flush VMA ranges affected by zap_page_range v2" in current mmotm. NOTE: This patch modifies arch-specific TLB gathering interface(x86, ia64, s390, sh, um). It seems most of architecture are straightforward but s390 need to be careful because tlb_flush_mmu works only if mm->context.flush_mm is set to non-zero which happens only a pte entry really is cleared by ptep_get_and_clear and friends. However, this problem never changes the pte entries but need to flush to prevent memory access from stale tlb. Any thoughts? [1] http://lkml.kernel.org/r/20170725101230.5v7gvnjmcnkzz...@techsingularity.net [2] http://lkml.kernel.org/r/20170725100722.2dxnmgypmwnrf...@suse.de [3] http://lkml.kernel.org/r/bd3a0ebe-ecf4-41d4-87fa-c755ea9ab...@gmail.com [4] https://patchwork.kernel.org/patch/9861621/ Cc: Ingo Molnar Cc: Russell King Cc: Tony Luck Cc: Martin Schwidefsky Cc: "David S. Miller" Cc: Heiko Carstens Cc: Yoshinori Sato Cc: Jeff Dike Cc: linux-a...@vger.kernel.org Cc: Nadav Amit Reported-by: Mel Gorman Signed-off-by: Minchan Kim --- arch/arm/include/asm/tlb.h | 7 ++- arch/ia64/include/asm/tlb.h | 4 +++- arch/s390/include/asm/tlb.h | 7 ++- arch/sh/include/asm/tlb.h | 4 ++-- arch/um/include/asm/tlb.h | 7 ++- include/asm-generic/tlb.h | 2 +- include/linux/mm_types.h| 8 mm/memory.c | 32 +--- 8 files changed, 49 insertions(+), 22 deletions(-) diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h index 7f5b2a2d3861..d5562f9ce600 100644 --- a/arch/arm/include/asm/tlb.h +++ b/arch/arm/include/asm/tlb.h @@ -168,8 +168,13 @@ arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, static inline void arch_tlb_finish_mmu(struct mmu_gather *tlb, - unsigned long start, unsigned long end) + unsigned long start, unsigned long end, bool force) { + if (force) { + tlb->range_start = start; + tlb->range_end = end; + } + tlb_flush_mmu(tlb); /* keep the page table cache within bounds */ diff --git a/arch/ia64/include/asm/tlb.h b/arch/ia64/include/asm/tlb.h index 93cadc04ac62..cbe5ac3699bf 100644 --- a/arch/ia64/include/asm/tlb.h +++ b/arch/ia64/include/asm/tlb.h @@ -187,8 +187,10 @@ arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, */ static inline void arch_tlb_finish_mmu(struct mmu_gather *tlb, - unsigned long start, unsigned long end) + unsigned long start, unsigned long end, bool force) { + if (force) + tlb->need_flush = 1; /* * Note: tlb->nr may be 0 at this point, so we can't rely on tlb->start_addr and * tlb->end_addr. diff --git a/arch/s390/include/asm/tlb.h b/arch/s390/include/asm/tlb.h index fa4b461694b7..3a14b864b2e3 100644 --- a/arch/s390/include/asm/tlb.h +++ b/arch/s390/include/asm/tlb.h @@ -77,8 +77,13 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb) static inline void arch_tlb_finish_mmu(struct mmu_gather *tlb, - unsigned long start, unsigned long end) + unsigned long start, unsigned long end, bool force) { + if (force) { + tlb->start = start; + tlb->end = end; + } + tlb_flush_mmu(tlb); } diff --git a/arch/sh/include/asm/tlb.h b/arch/sh/include/asm/tlb.h index 89786560dbd4..51a8bc967e75 100644 ---
[PATCH v2 1/4] mm: refactoring TLB gathering API
This patch is ready for solving race problems caused by TLB batch. For that, we will increase/decrease TLB flush pending count of mm_struct whenever tlb_[gather|finish]_mmu is called. Before making it simple, this patch separates architecture specific part and rename it to arch_tlb_[gather|finish]_mmu and generic part just calls it. It shouldn't change any behavior. Cc: Ingo MolnarCc: Russell King Cc: Tony Luck Cc: Martin Schwidefsky Cc: "David S. Miller" Cc: Heiko Carstens Cc: Yoshinori Sato Cc: Jeff Dike Cc: linux-a...@vger.kernel.org Cc: Nadav Amit Cc: Mel Gorman Signed-off-by: Minchan Kim --- arch/arm/include/asm/tlb.h | 6 -- arch/ia64/include/asm/tlb.h | 6 -- arch/s390/include/asm/tlb.h | 12 ++-- arch/sh/include/asm/tlb.h | 6 -- arch/um/include/asm/tlb.h | 8 +--- include/asm-generic/tlb.h | 7 --- include/linux/mm_types.h| 6 ++ mm/memory.c | 36 +--- 8 files changed, 62 insertions(+), 25 deletions(-) diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h index 3f2eb76243e3..7f5b2a2d3861 100644 --- a/arch/arm/include/asm/tlb.h +++ b/arch/arm/include/asm/tlb.h @@ -148,7 +148,8 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb) } static inline void -tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long start, unsigned long end) +arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, + unsigned long start, unsigned long end) { tlb->mm = mm; tlb->fullmm = !(start | (end+1)); @@ -166,7 +167,8 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long start } static inline void -tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end) +arch_tlb_finish_mmu(struct mmu_gather *tlb, + unsigned long start, unsigned long end) { tlb_flush_mmu(tlb); diff --git a/arch/ia64/include/asm/tlb.h b/arch/ia64/include/asm/tlb.h index fced197b9626..93cadc04ac62 100644 --- a/arch/ia64/include/asm/tlb.h +++ b/arch/ia64/include/asm/tlb.h @@ -168,7 +168,8 @@ static inline void __tlb_alloc_page(struct mmu_gather *tlb) static inline void -tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long start, unsigned long end) +arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, + unsigned long start, unsigned long end) { tlb->mm = mm; tlb->max = ARRAY_SIZE(tlb->local); @@ -185,7 +186,8 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long start * collected. */ static inline void -tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end) +arch_tlb_finish_mmu(struct mmu_gather *tlb, + unsigned long start, unsigned long end) { /* * Note: tlb->nr may be 0 at this point, so we can't rely on tlb->start_addr and diff --git a/arch/s390/include/asm/tlb.h b/arch/s390/include/asm/tlb.h index 950af48e88be..fa4b461694b7 100644 --- a/arch/s390/include/asm/tlb.h +++ b/arch/s390/include/asm/tlb.h @@ -47,10 +47,9 @@ struct mmu_table_batch { extern void tlb_table_flush(struct mmu_gather *tlb); extern void tlb_remove_table(struct mmu_gather *tlb, void *table); -static inline void tlb_gather_mmu(struct mmu_gather *tlb, - struct mm_struct *mm, - unsigned long start, - unsigned long end) +static inline void +arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, + unsigned long start, unsigned long end) { tlb->mm = mm; tlb->start = start; @@ -76,8 +75,9 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb) tlb_flush_mmu_free(tlb); } -static inline void tlb_finish_mmu(struct mmu_gather *tlb, - unsigned long start, unsigned long end) +static inline void +arch_tlb_finish_mmu(struct mmu_gather *tlb, + unsigned long start, unsigned long end) { tlb_flush_mmu(tlb); } diff --git a/arch/sh/include/asm/tlb.h b/arch/sh/include/asm/tlb.h index 46e0d635e36f..89786560dbd4 100644 --- a/arch/sh/include/asm/tlb.h +++ b/arch/sh/include/asm/tlb.h @@ -36,7 +36,8 @@ static inline void init_tlb_gather(struct mmu_gather *tlb) } static inline void -tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long start, unsigned long end) +arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, + unsigned long start, unsigned long end) { tlb->mm = mm; tlb->start = start; @@ -47,7 +48,8 @@
[PATCH v2 1/4] mm: refactoring TLB gathering API
This patch is ready for solving race problems caused by TLB batch. For that, we will increase/decrease TLB flush pending count of mm_struct whenever tlb_[gather|finish]_mmu is called. Before making it simple, this patch separates architecture specific part and rename it to arch_tlb_[gather|finish]_mmu and generic part just calls it. It shouldn't change any behavior. Cc: Ingo Molnar Cc: Russell King Cc: Tony Luck Cc: Martin Schwidefsky Cc: "David S. Miller" Cc: Heiko Carstens Cc: Yoshinori Sato Cc: Jeff Dike Cc: linux-a...@vger.kernel.org Cc: Nadav Amit Cc: Mel Gorman Signed-off-by: Minchan Kim --- arch/arm/include/asm/tlb.h | 6 -- arch/ia64/include/asm/tlb.h | 6 -- arch/s390/include/asm/tlb.h | 12 ++-- arch/sh/include/asm/tlb.h | 6 -- arch/um/include/asm/tlb.h | 8 +--- include/asm-generic/tlb.h | 7 --- include/linux/mm_types.h| 6 ++ mm/memory.c | 36 +--- 8 files changed, 62 insertions(+), 25 deletions(-) diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h index 3f2eb76243e3..7f5b2a2d3861 100644 --- a/arch/arm/include/asm/tlb.h +++ b/arch/arm/include/asm/tlb.h @@ -148,7 +148,8 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb) } static inline void -tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long start, unsigned long end) +arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, + unsigned long start, unsigned long end) { tlb->mm = mm; tlb->fullmm = !(start | (end+1)); @@ -166,7 +167,8 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long start } static inline void -tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end) +arch_tlb_finish_mmu(struct mmu_gather *tlb, + unsigned long start, unsigned long end) { tlb_flush_mmu(tlb); diff --git a/arch/ia64/include/asm/tlb.h b/arch/ia64/include/asm/tlb.h index fced197b9626..93cadc04ac62 100644 --- a/arch/ia64/include/asm/tlb.h +++ b/arch/ia64/include/asm/tlb.h @@ -168,7 +168,8 @@ static inline void __tlb_alloc_page(struct mmu_gather *tlb) static inline void -tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long start, unsigned long end) +arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, + unsigned long start, unsigned long end) { tlb->mm = mm; tlb->max = ARRAY_SIZE(tlb->local); @@ -185,7 +186,8 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long start * collected. */ static inline void -tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end) +arch_tlb_finish_mmu(struct mmu_gather *tlb, + unsigned long start, unsigned long end) { /* * Note: tlb->nr may be 0 at this point, so we can't rely on tlb->start_addr and diff --git a/arch/s390/include/asm/tlb.h b/arch/s390/include/asm/tlb.h index 950af48e88be..fa4b461694b7 100644 --- a/arch/s390/include/asm/tlb.h +++ b/arch/s390/include/asm/tlb.h @@ -47,10 +47,9 @@ struct mmu_table_batch { extern void tlb_table_flush(struct mmu_gather *tlb); extern void tlb_remove_table(struct mmu_gather *tlb, void *table); -static inline void tlb_gather_mmu(struct mmu_gather *tlb, - struct mm_struct *mm, - unsigned long start, - unsigned long end) +static inline void +arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, + unsigned long start, unsigned long end) { tlb->mm = mm; tlb->start = start; @@ -76,8 +75,9 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb) tlb_flush_mmu_free(tlb); } -static inline void tlb_finish_mmu(struct mmu_gather *tlb, - unsigned long start, unsigned long end) +static inline void +arch_tlb_finish_mmu(struct mmu_gather *tlb, + unsigned long start, unsigned long end) { tlb_flush_mmu(tlb); } diff --git a/arch/sh/include/asm/tlb.h b/arch/sh/include/asm/tlb.h index 46e0d635e36f..89786560dbd4 100644 --- a/arch/sh/include/asm/tlb.h +++ b/arch/sh/include/asm/tlb.h @@ -36,7 +36,8 @@ static inline void init_tlb_gather(struct mmu_gather *tlb) } static inline void -tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long start, unsigned long end) +arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, + unsigned long start, unsigned long end) { tlb->mm = mm; tlb->start = start; @@ -47,7 +48,8 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long start } static inline void -tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end) +arch_tlb_finish_mmu(struct mmu_gather *tlb, + unsigned long
[PATCH v2 2/4] mm: make tlb_flush_pending global
Currently, tlb_flush_pending is used only for CONFIG_[NUMA_BALANCING| COMPACTION] but upcoming patches to solve subtle TLB flush bacting problem will use it regardless of compaction/numa so this patch doesn't remove the dependency. Cc: Nadav AmitCc: Mel Gorman Signed-off-by: Minchan Kim --- include/linux/mm_types.h | 21 - mm/debug.c | 2 -- 2 files changed, 23 deletions(-) diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h index c605f2a3a68e..892a7b0196fd 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -487,14 +487,12 @@ struct mm_struct { /* numa_scan_seq prevents two threads setting pte_numa */ int numa_scan_seq; #endif -#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION) /* * An operation with batched TLB flushing is going on. Anything that * can move process memory needs to flush the TLB when moving a * PROT_NONE or PROT_NUMA mapped page. */ atomic_t tlb_flush_pending; -#endif #ifdef CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH /* See flush_tlb_batched_pending() */ bool tlb_flush_batched; @@ -528,7 +526,6 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, extern void tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end); -#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION) /* * Memory barriers to keep this state in sync are graciously provided by * the page table locks, outside of which no page table modifications happen. @@ -569,24 +566,6 @@ static inline void dec_tlb_flush_pending(struct mm_struct *mm) smp_mb__before_atomic(); atomic_dec(>tlb_flush_pending); } -#else -static inline bool mm_tlb_flush_pending(struct mm_struct *mm) -{ - return false; -} - -static inline void init_tlb_flush_pending(struct mm_struct *mm) -{ -} - -static inline void inc_tlb_flush_pending(struct mm_struct *mm) -{ -} - -static inline void dec_tlb_flush_pending(struct mm_struct *mm) -{ -} -#endif struct vm_fault; diff --git a/mm/debug.c b/mm/debug.c index d70103bb4731..18a9b15b1e37 100644 --- a/mm/debug.c +++ b/mm/debug.c @@ -158,9 +158,7 @@ void dump_mm(const struct mm_struct *mm) #ifdef CONFIG_NUMA_BALANCING mm->numa_next_scan, mm->numa_scan_offset, mm->numa_scan_seq, #endif -#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION) atomic_read(>tlb_flush_pending), -#endif mm->def_flags, >def_flags ); } -- 2.7.4
[PATCH v2 2/4] mm: make tlb_flush_pending global
Currently, tlb_flush_pending is used only for CONFIG_[NUMA_BALANCING| COMPACTION] but upcoming patches to solve subtle TLB flush bacting problem will use it regardless of compaction/numa so this patch doesn't remove the dependency. Cc: Nadav Amit Cc: Mel Gorman Signed-off-by: Minchan Kim --- include/linux/mm_types.h | 21 - mm/debug.c | 2 -- 2 files changed, 23 deletions(-) diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h index c605f2a3a68e..892a7b0196fd 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -487,14 +487,12 @@ struct mm_struct { /* numa_scan_seq prevents two threads setting pte_numa */ int numa_scan_seq; #endif -#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION) /* * An operation with batched TLB flushing is going on. Anything that * can move process memory needs to flush the TLB when moving a * PROT_NONE or PROT_NUMA mapped page. */ atomic_t tlb_flush_pending; -#endif #ifdef CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH /* See flush_tlb_batched_pending() */ bool tlb_flush_batched; @@ -528,7 +526,6 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, extern void tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end); -#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION) /* * Memory barriers to keep this state in sync are graciously provided by * the page table locks, outside of which no page table modifications happen. @@ -569,24 +566,6 @@ static inline void dec_tlb_flush_pending(struct mm_struct *mm) smp_mb__before_atomic(); atomic_dec(>tlb_flush_pending); } -#else -static inline bool mm_tlb_flush_pending(struct mm_struct *mm) -{ - return false; -} - -static inline void init_tlb_flush_pending(struct mm_struct *mm) -{ -} - -static inline void inc_tlb_flush_pending(struct mm_struct *mm) -{ -} - -static inline void dec_tlb_flush_pending(struct mm_struct *mm) -{ -} -#endif struct vm_fault; diff --git a/mm/debug.c b/mm/debug.c index d70103bb4731..18a9b15b1e37 100644 --- a/mm/debug.c +++ b/mm/debug.c @@ -158,9 +158,7 @@ void dump_mm(const struct mm_struct *mm) #ifdef CONFIG_NUMA_BALANCING mm->numa_next_scan, mm->numa_scan_offset, mm->numa_scan_seq, #endif -#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION) atomic_read(>tlb_flush_pending), -#endif mm->def_flags, >def_flags ); } -- 2.7.4
[PATCH v2 0/4] fix several TLB batch races
Nadav and Mel founded several subtle races caused by TLB batching. This patchset aims for solving thoses problems using embedding [inc|dec]_tlb_flush_pending to TLB batching API. With that, places to know TLB flush pending catch it up by using mm_tlb_flush_pending. Each patch includes detailed description. This patchset is based on v4.13-rc2-mmots-2017-07-28-16-10 + "[PATCH v5 0/3] mm: fixes of tlb_flush_pending races" from Nadav * from v1 * TLB batching API separation core part from arch specific one - Mel * introduce mm_tlb_flush_nested - Mel Minchan Kim (4): mm: refactoring TLB gathering API mm: make tlb_flush_pending global mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem mm: fix KSM data corruption arch/arm/include/asm/tlb.h | 11 ++-- arch/ia64/include/asm/tlb.h | 8 -- arch/s390/include/asm/tlb.h | 17 - arch/sh/include/asm/tlb.h | 8 +++--- arch/um/include/asm/tlb.h | 13 +++--- fs/proc/task_mmu.c | 4 ++- include/asm-generic/tlb.h | 7 ++--- include/linux/mm_types.h| 35 ++--- mm/debug.c | 2 -- mm/ksm.c| 3 ++- mm/memory.c | 62 +++-- 11 files changed, 107 insertions(+), 63 deletions(-) -- 2.7.4
[PATCH v2 4/4] mm: fix KSM data corruption
Nadav reported KSM can corrupt the user data by the TLB batching race[1]. That means data user written can be lost. Quote from Nadav Amit " For this race we need 4 CPUs: CPU0: Caches a writable and dirty PTE entry, and uses the stale value for write later. CPU1: Runs madvise_free on the range that includes the PTE. It would clear the dirty-bit. It batches TLB flushes. CPU2: Writes 4 to /proc/PID/clear_refs , clearing the PTEs soft-dirty. We care about the fact that it clears the PTE write-bit, and of course, batches TLB flushes. CPU3: Runs KSM. Our purpose is to pass the following test in write_protect_page(): if (pte_write(*pvmw.pte) || pte_dirty(*pvmw.pte) || (pte_protnone(*pvmw.pte) && pte_savedwrite(*pvmw.pte))) Since it will avoid TLB flush. And we want to do it while the PTE is stale. Later, and before replacing the page, we would be able to change the page. Note that all the operations the CPU1-3 perform canhappen in parallel since they only acquire mmap_sem for read. We start with two identical pages. Everything below regards the same page/PTE. CPU0CPU1CPU2CPU3 Write the same value on page [cache PTE as dirty in TLB] MADV_FREE pte_mkclean() 4 > clear_refs pte_wrprotect() write_protect_page() [ success, no flush ] pages_indentical() [ ok ] Write to page different value [Ok, using stale PTE] replace_page() Later, CPU1, CPU2 and CPU3 would flush the TLB, but that is too late. CPU0 already wrote on the page, but KSM ignored this write, and it got lost. " In above scenario, MADV_FREE is fixed by changing TLB batching API including [set|clear]_tlb_flush_pending. Remained thing is soft-dirty part. This patch changes soft-dirty uses TLB batching API instead of flush_tlb_mm and KSM checks pending TLB flush by using mm_tlb_flush_pending so that it will flush TLB to avoid data lost if there are other parallel threads pending TLB flush. [1] http://lkml.kernel.org/r/bd3a0ebe-ecf4-41d4-87fa-c755ea9ab...@gmail.com Note: I failed to reproduce this problem through Nadav's test program which need to tune timing in my system speed so didn't confirm it work. Nadav, Could you test this patch on your test machine? Thanks! Cc: Nadav AmitCc: Mel Gorman Cc: Hugh Dickins Cc: Andrea Arcangeli Signed-off-by: Minchan Kim --- fs/proc/task_mmu.c | 4 +++- mm/ksm.c | 3 ++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 9782dedeead7..58ef3a6abbc0 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -1018,6 +1018,7 @@ static ssize_t clear_refs_write(struct file *file, const char __user *buf, enum clear_refs_types type; int itype; int rv; + struct mmu_gather tlb; memset(buffer, 0, sizeof(buffer)); if (count > sizeof(buffer) - 1) @@ -1062,6 +1063,7 @@ static ssize_t clear_refs_write(struct file *file, const char __user *buf, } down_read(>mmap_sem); + tlb_gather_mmu(, mm, 0, -1); if (type == CLEAR_REFS_SOFT_DIRTY) { for (vma = mm->mmap; vma; vma = vma->vm_next) { if (!(vma->vm_flags & VM_SOFTDIRTY)) @@ -1083,7 +1085,7 @@ static ssize_t clear_refs_write(struct file *file, const char __user *buf, walk_page_range(0, mm->highest_vm_end, _refs_walk); if (type == CLEAR_REFS_SOFT_DIRTY) mmu_notifier_invalidate_range_end(mm, 0, -1); - flush_tlb_mm(mm); + tlb_finish_mmu(, 0, -1); up_read(>mmap_sem); out_mm: mmput(mm); diff --git a/mm/ksm.c b/mm/ksm.c index 0c927e36a639..15dd7415f7b3 100644 --- a/mm/ksm.c +++ b/mm/ksm.c @@ -1038,7 +1038,8 @@ static int write_protect_page(struct vm_area_struct *vma, struct page *page, goto out_unlock; if (pte_write(*pvmw.pte) || pte_dirty(*pvmw.pte) || - (pte_protnone(*pvmw.pte) && pte_savedwrite(*pvmw.pte))) { + (pte_protnone(*pvmw.pte) && pte_savedwrite(*pvmw.pte)) || + mm_tlb_flush_pending(mm)) { pte_t entry; swapped = PageSwapCache(page); -- 2.7.4
[PATCH v2 0/4] fix several TLB batch races
Nadav and Mel founded several subtle races caused by TLB batching. This patchset aims for solving thoses problems using embedding [inc|dec]_tlb_flush_pending to TLB batching API. With that, places to know TLB flush pending catch it up by using mm_tlb_flush_pending. Each patch includes detailed description. This patchset is based on v4.13-rc2-mmots-2017-07-28-16-10 + "[PATCH v5 0/3] mm: fixes of tlb_flush_pending races" from Nadav * from v1 * TLB batching API separation core part from arch specific one - Mel * introduce mm_tlb_flush_nested - Mel Minchan Kim (4): mm: refactoring TLB gathering API mm: make tlb_flush_pending global mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem mm: fix KSM data corruption arch/arm/include/asm/tlb.h | 11 ++-- arch/ia64/include/asm/tlb.h | 8 -- arch/s390/include/asm/tlb.h | 17 - arch/sh/include/asm/tlb.h | 8 +++--- arch/um/include/asm/tlb.h | 13 +++--- fs/proc/task_mmu.c | 4 ++- include/asm-generic/tlb.h | 7 ++--- include/linux/mm_types.h| 35 ++--- mm/debug.c | 2 -- mm/ksm.c| 3 ++- mm/memory.c | 62 +++-- 11 files changed, 107 insertions(+), 63 deletions(-) -- 2.7.4
[PATCH v2 4/4] mm: fix KSM data corruption
Nadav reported KSM can corrupt the user data by the TLB batching race[1]. That means data user written can be lost. Quote from Nadav Amit " For this race we need 4 CPUs: CPU0: Caches a writable and dirty PTE entry, and uses the stale value for write later. CPU1: Runs madvise_free on the range that includes the PTE. It would clear the dirty-bit. It batches TLB flushes. CPU2: Writes 4 to /proc/PID/clear_refs , clearing the PTEs soft-dirty. We care about the fact that it clears the PTE write-bit, and of course, batches TLB flushes. CPU3: Runs KSM. Our purpose is to pass the following test in write_protect_page(): if (pte_write(*pvmw.pte) || pte_dirty(*pvmw.pte) || (pte_protnone(*pvmw.pte) && pte_savedwrite(*pvmw.pte))) Since it will avoid TLB flush. And we want to do it while the PTE is stale. Later, and before replacing the page, we would be able to change the page. Note that all the operations the CPU1-3 perform canhappen in parallel since they only acquire mmap_sem for read. We start with two identical pages. Everything below regards the same page/PTE. CPU0CPU1CPU2CPU3 Write the same value on page [cache PTE as dirty in TLB] MADV_FREE pte_mkclean() 4 > clear_refs pte_wrprotect() write_protect_page() [ success, no flush ] pages_indentical() [ ok ] Write to page different value [Ok, using stale PTE] replace_page() Later, CPU1, CPU2 and CPU3 would flush the TLB, but that is too late. CPU0 already wrote on the page, but KSM ignored this write, and it got lost. " In above scenario, MADV_FREE is fixed by changing TLB batching API including [set|clear]_tlb_flush_pending. Remained thing is soft-dirty part. This patch changes soft-dirty uses TLB batching API instead of flush_tlb_mm and KSM checks pending TLB flush by using mm_tlb_flush_pending so that it will flush TLB to avoid data lost if there are other parallel threads pending TLB flush. [1] http://lkml.kernel.org/r/bd3a0ebe-ecf4-41d4-87fa-c755ea9ab...@gmail.com Note: I failed to reproduce this problem through Nadav's test program which need to tune timing in my system speed so didn't confirm it work. Nadav, Could you test this patch on your test machine? Thanks! Cc: Nadav Amit Cc: Mel Gorman Cc: Hugh Dickins Cc: Andrea Arcangeli Signed-off-by: Minchan Kim --- fs/proc/task_mmu.c | 4 +++- mm/ksm.c | 3 ++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 9782dedeead7..58ef3a6abbc0 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -1018,6 +1018,7 @@ static ssize_t clear_refs_write(struct file *file, const char __user *buf, enum clear_refs_types type; int itype; int rv; + struct mmu_gather tlb; memset(buffer, 0, sizeof(buffer)); if (count > sizeof(buffer) - 1) @@ -1062,6 +1063,7 @@ static ssize_t clear_refs_write(struct file *file, const char __user *buf, } down_read(>mmap_sem); + tlb_gather_mmu(, mm, 0, -1); if (type == CLEAR_REFS_SOFT_DIRTY) { for (vma = mm->mmap; vma; vma = vma->vm_next) { if (!(vma->vm_flags & VM_SOFTDIRTY)) @@ -1083,7 +1085,7 @@ static ssize_t clear_refs_write(struct file *file, const char __user *buf, walk_page_range(0, mm->highest_vm_end, _refs_walk); if (type == CLEAR_REFS_SOFT_DIRTY) mmu_notifier_invalidate_range_end(mm, 0, -1); - flush_tlb_mm(mm); + tlb_finish_mmu(, 0, -1); up_read(>mmap_sem); out_mm: mmput(mm); diff --git a/mm/ksm.c b/mm/ksm.c index 0c927e36a639..15dd7415f7b3 100644 --- a/mm/ksm.c +++ b/mm/ksm.c @@ -1038,7 +1038,8 @@ static int write_protect_page(struct vm_area_struct *vma, struct page *page, goto out_unlock; if (pte_write(*pvmw.pte) || pte_dirty(*pvmw.pte) || - (pte_protnone(*pvmw.pte) && pte_savedwrite(*pvmw.pte))) { + (pte_protnone(*pvmw.pte) && pte_savedwrite(*pvmw.pte)) || + mm_tlb_flush_pending(mm)) { pte_t entry; swapped = PageSwapCache(page); -- 2.7.4
Re: [RFC]Add new mdev interface for QoS
On 2017/7/28 0:00, Gao, Ping A wrote: > On 2017/7/27 0:43, Alex Williamson wrote: >> [cc +libvir-list] >> >> On Wed, 26 Jul 2017 21:16:59 +0800 >> "Gao, Ping A"wrote: >> >>> The vfio-mdev provide the capability to let different guest share the >>> same physical device through mediate sharing, as result it bring a >>> requirement about how to control the device sharing, we need a QoS >>> related interface for mdev to management virtual device resource. >>> >>> E.g. In practical use, vGPUs assigned to different quests almost has >>> different performance requirements, some guests may need higher priority >>> for real time usage, some other may need more portion of the GPU >>> resource to get higher 3D performance, corresponding we can define some >>> interfaces like weight/cap for overall budget control, priority for >>> single submission control. >>> >>> So I suggest to add some common attributes which are vendor agnostic in >>> mdev core sysfs for QoS purpose. >> I think what you're asking for is just some standardization of a QoS >> attribute_group which a vendor can optionally include within the >> existing mdev_parent_ops.mdev_attr_groups. The mdev core will >> transparently enable this, but it really only provides the standard, >> all of the support code is left for the vendor. I'm fine with that, >> but of course the trouble with and sort of standardization is arriving >> at an agreed upon standard. Are there QoS knobs that are generic >> across any mdev device type? Are there others that are more specific >> to vGPU? Are there existing examples of this that we can steal their >> specification? > Yes, you are right, standardization QoS knobs are exactly what I wanted. > Only when it become a part of the mdev framework and libvirt, then QoS > such critical feature can be leveraged by cloud usage. HW vendor only > need to focus on the implementation of the corresponding QoS algorithm > in their back-end driver. > > Vfio-mdev framework provide the capability to share the device that lack > of HW virtualization support to guests, no matter the device type, > mediated sharing actually is a time sharing multiplex method, from this > point of view, QoS can be take as a generic way about how to control the > time assignment for virtual mdev device that occupy HW. As result we can > define QoS knob generic across any device type by this way. Even if HW > has build in with some kind of QoS support, I think it's not a problem > for back-end driver to convert mdev standard QoS definition to their > specification to reach the same performance expectation. Seems there are > no examples for us to follow, we need define it from scratch. > > I proposal universal QoS control interfaces like below: > > Cap: The cap limits the maximum percentage of time a mdev device can own > physical device. e.g. cap=60, means mdev device cannot take over 60% of > total physical resource. > > Weight: The weight define proportional control of the mdev device > resource between guests, it’s orthogonal with Cap, to target load > balancing. E.g. if guest 1 should take double mdev device resource > compare with guest 2, need set weight ratio to 2:1. > > Priority: The guest who has higher priority will get execution first, > target to some real time usage and speeding interactive response. > > Above QoS interfaces cover both overall budget control and single > submission control. I will sent out detail design later once get aligned. Hi Alex, Any comments about the interface mentioned above? >> Also, mdev devices are not necessarily the exclusive users of the >> hardware, we can have a native user such as a local X client. They're >> not an mdev user, so we can't support them via the mdev_attr_group. >> Does there need to be a per mdev parent QoS attribute_group standard >> for somehow defining the QoS of all the child mdev devices, or perhaps >> representing the remaining host QoS attributes? > That's really an open, if we don't take host workload into consideration > for cloud usage, it's not a problem any more, however such assumption is > not reasonable. Any way if we take mdev devices as clients of host > driver, and host driver provide the capability to divide out a portion > HW resource to mdev devices, then it's only need to take care about the > resource that host assigned for mdev devices. Follow this way QoS for > mdev focus on the relationship between mdev devices no need to take care > the host workload. > > -Ping > >> Ultimately libvirt and upper level management tools would be the >> consumer of these control knobs, so let's immediately get libvirt >> involved in the discussion. Thanks, >> >> Alex
Re: [RFC]Add new mdev interface for QoS
On 2017/7/28 0:00, Gao, Ping A wrote: > On 2017/7/27 0:43, Alex Williamson wrote: >> [cc +libvir-list] >> >> On Wed, 26 Jul 2017 21:16:59 +0800 >> "Gao, Ping A" wrote: >> >>> The vfio-mdev provide the capability to let different guest share the >>> same physical device through mediate sharing, as result it bring a >>> requirement about how to control the device sharing, we need a QoS >>> related interface for mdev to management virtual device resource. >>> >>> E.g. In practical use, vGPUs assigned to different quests almost has >>> different performance requirements, some guests may need higher priority >>> for real time usage, some other may need more portion of the GPU >>> resource to get higher 3D performance, corresponding we can define some >>> interfaces like weight/cap for overall budget control, priority for >>> single submission control. >>> >>> So I suggest to add some common attributes which are vendor agnostic in >>> mdev core sysfs for QoS purpose. >> I think what you're asking for is just some standardization of a QoS >> attribute_group which a vendor can optionally include within the >> existing mdev_parent_ops.mdev_attr_groups. The mdev core will >> transparently enable this, but it really only provides the standard, >> all of the support code is left for the vendor. I'm fine with that, >> but of course the trouble with and sort of standardization is arriving >> at an agreed upon standard. Are there QoS knobs that are generic >> across any mdev device type? Are there others that are more specific >> to vGPU? Are there existing examples of this that we can steal their >> specification? > Yes, you are right, standardization QoS knobs are exactly what I wanted. > Only when it become a part of the mdev framework and libvirt, then QoS > such critical feature can be leveraged by cloud usage. HW vendor only > need to focus on the implementation of the corresponding QoS algorithm > in their back-end driver. > > Vfio-mdev framework provide the capability to share the device that lack > of HW virtualization support to guests, no matter the device type, > mediated sharing actually is a time sharing multiplex method, from this > point of view, QoS can be take as a generic way about how to control the > time assignment for virtual mdev device that occupy HW. As result we can > define QoS knob generic across any device type by this way. Even if HW > has build in with some kind of QoS support, I think it's not a problem > for back-end driver to convert mdev standard QoS definition to their > specification to reach the same performance expectation. Seems there are > no examples for us to follow, we need define it from scratch. > > I proposal universal QoS control interfaces like below: > > Cap: The cap limits the maximum percentage of time a mdev device can own > physical device. e.g. cap=60, means mdev device cannot take over 60% of > total physical resource. > > Weight: The weight define proportional control of the mdev device > resource between guests, it’s orthogonal with Cap, to target load > balancing. E.g. if guest 1 should take double mdev device resource > compare with guest 2, need set weight ratio to 2:1. > > Priority: The guest who has higher priority will get execution first, > target to some real time usage and speeding interactive response. > > Above QoS interfaces cover both overall budget control and single > submission control. I will sent out detail design later once get aligned. Hi Alex, Any comments about the interface mentioned above? >> Also, mdev devices are not necessarily the exclusive users of the >> hardware, we can have a native user such as a local X client. They're >> not an mdev user, so we can't support them via the mdev_attr_group. >> Does there need to be a per mdev parent QoS attribute_group standard >> for somehow defining the QoS of all the child mdev devices, or perhaps >> representing the remaining host QoS attributes? > That's really an open, if we don't take host workload into consideration > for cloud usage, it's not a problem any more, however such assumption is > not reasonable. Any way if we take mdev devices as clients of host > driver, and host driver provide the capability to divide out a portion > HW resource to mdev devices, then it's only need to take care about the > resource that host assigned for mdev devices. Follow this way QoS for > mdev focus on the relationship between mdev devices no need to take care > the host workload. > > -Ping > >> Ultimately libvirt and upper level management tools would be the >> consumer of these control knobs, so let's immediately get libvirt >> involved in the discussion. Thanks, >> >> Alex
linux-next: manual merge of the akpm tree with the wberr tree
Hi Andrew, Today's linux-next merge of the akpm-current tree got a conflict in: include/linux/fs.h between commit: 9dcc0577f2a4 ("mm: remove optimizations based on i_size in mapping writeback waits") from the wberr tree and patch: "mm: remove optimizations based on i_size in mapping writeback waits" from the akpm tree. I fixed it up (I just dropped the akpm tree patch) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell
linux-next: manual merge of the akpm tree with the wberr tree
Hi Andrew, Today's linux-next merge of the akpm-current tree got a conflict in: include/linux/fs.h between commit: 9dcc0577f2a4 ("mm: remove optimizations based on i_size in mapping writeback waits") from the wberr tree and patch: "mm: remove optimizations based on i_size in mapping writeback waits" from the akpm tree. I fixed it up (I just dropped the akpm tree patch) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell
Re: [PATCH V3] pci: quirk: Apply APM ACS quirk to XGene devices
On Mon, Jul 31, 2017 at 2:55 PM, Alex Williamsonwrote: > On Mon, 31 Jul 2017 10:56:53 -0700 > Feng Kan wrote: > >> On Fri, Jul 28, 2017 at 4:00 PM, Alex Williamson >> wrote: >> > On Fri, 28 Jul 2017 11:50:43 -0700 >> > Feng Kan wrote: >> > >> >> The APM X-Gene PCIe root port does not support ACS at this point. >> >> However, the hw provides isolation and source validation through >> >> the SMMU. The stream ID generated by the PCIe ports contain both >> >> the BDF as well as the port ID in its 3 most significant bits. >> >> Turn on ACS but disable all the peer to peer features. >> >> >> >> Signed-off-by: Feng Kan >> >> --- >> >> V3 Change: Add comment regarding unique port id in stream ID >> >> V2 Change: Move XGene ACS quirk to unique XGene function >> >> >> >> drivers/pci/quirks.c | 15 +++ >> >> 1 file changed, 15 insertions(+) >> >> >> >> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c >> >> index 085fb78..0f8f1cd 100644 >> >> --- a/drivers/pci/quirks.c >> >> +++ b/drivers/pci/quirks.c >> >> @@ -4120,6 +4120,19 @@ static int pci_quirk_cavium_acs(struct pci_dev >> >> *dev, u16 acs_flags) >> >> return acs_flags ? 0 : 1; >> >> } >> >> >> >> +static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags) >> >> +{ >> >> + /* >> >> + * XGene root matching this quirk do not allow peer-to-peer >> >> + * transactions with others, allowing masking out these bits as if >> >> they >> >> + * were unimplemented in the ACS capability. >> >> + */ >> >> + acs_flags &= ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR | >> >> +PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT); >> >> + >> >> + return acs_flags ? 0 : 1; >> >> +} >> >> + >> >> /* >> >> * Many Intel PCH root ports do provide ACS-like features to disable peer >> >> * transactions and validate bus numbers in requests, but do not provide >> >> an >> >> @@ -4368,6 +4381,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev >> >> *dev, u16 acs_flags) >> >> { 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */ >> >> /* Cavium ThunderX */ >> >> { PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs }, >> >> + /* APM XGene */ >> >> + { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs }, >> >> { 0 } >> >> }; >> >> >> > >> > Hi Feng, >> > >> > Sorry, I have one more question as I happened to spend some time >> > looking at PCI_ACS_DT this week. DT specifies that peer-to-peer should >> > occur normally between egress ports for transactions which are >> > pre-translated by an ATS unit on the endpoint. Therefore if a root >> > port doesn't allow peer-to-peer, it seems like it should not claim to >> > support PCI_ACS_DT. I know your quirk is just a copy of the Cavium >> > one, but we should also go back and verify this question with them, or >> > perhaps I'm misinterpreting this capability. AIUI this is also a >> > performance capability, not an isolation capability, so it shouldn't >> > affect the ability to consider a device isolated, it only gets >> > confusing if we expect a performance benefit from this but don't >> > actually see one. Does your root port have this ability to >> > selectively allow peer-to-peer of pre-translated transactions? Thanks, >> We do not support peer to peer between root ports (each root port is a >> root complex in itself). >> Therefore, this bit set/unset has no effect. >> >> As one of our guys pointed out in PCIe 3.1a, it may help address your >> concern above. >> >> """ >> Root Port indication of ACS Direct Translated P2P support does not imply any >> particular level of peer-to-peer support by the Root Complex, or that >> peer-to-peer traffic is supported at all. >> """ > > That's interesting, but is that referring to the ACS capability or the > control? I could imagine how advertising the capability would not > imply any particular level of p2p, but enabling the control (which is > what we're claiming via this quirk) the spec states: > > When ACS Direct Translated P2P is enabled in a Downstream Port, > peer-to-peer Memory Requests whose Address Type (AT) field indicates > a Translated address must be routed normally (“directly”) to the peer > Egress Port, regardless of ACS P2P Request Redirect and ACS P2P > Egress Control settings. All other peer-to-peer Requests must still > be subject to ACS P2P Request Redirect and ACS P2P Egress Control > settings. > > Note the *must* phrasing. Furthermore, 7.16.3: > > ACS Direct Translated P2P Enable (T) – When Set, overrides the ACS > P2P Request Redirect and ACS P2P Egress Control mechanisms with > peer-to-peer Memory Requests whose Address Translation (AT) field > indicates a Translated address (see Section 6.12.3). > > This bit is ignored if ACS Translation Blocking Enable (B) is 1b. > > Default value of this bit is 0b.
Re: [GIT PULL] Please pull NFS client changes for Linux 4.13
On Mon, Jul 31, 2017 at 8:43 AM, da...@codemonkey.org.ukwrote: > Another NFSv4 KASAN splat, this time from rc3. > > BUG: KASAN: use-after-free in nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4] Ugh. It's really hard to tell what access that it - KASAN doesn't actually give enough information. There's lots of 8-byte accesses there in that function. Any chance of getting the output from ./scripts/faddr2line vmlinux nfs4_exchange_id_done+0x3d7/0x8e0 or something? That would be extremely useful in general for stacktraces, but it's doubly useful for KASAN because most *other* stacktraces tend to have a very limited number of things that can warn (ie there's one or two WARN_ON() calls in a function), but KASAN can have tens or hundreds.. Linus > Read of size 8 at addr 8804508af528 by task kworker/2:1/34 > > CPU: 2 PID: 34 Comm: kworker/2:1 Not tainted 4.13.0-rc3-think+ #1 > Workqueue: rpciod rpc_async_schedule [sunrpc] > Call Trace: > dump_stack+0x68/0xa1 > print_address_description+0xd9/0x270 > kasan_report+0x257/0x370 > ? nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4] > check_memory_region+0x13a/0x1a0 > __asan_loadN+0xf/0x20 > nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4] > ? nfs4_exchange_id_release+0xb0/0xb0 [nfsv4] > rpc_exit_task+0x69/0x110 [sunrpc] > ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc] > ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc] > __rpc_execute+0x1a0/0x840 [sunrpc] > ? rpc_wake_up_queued_task+0x50/0x50 [sunrpc] > ? __lock_is_held+0x9a/0x100 > ? debug_lockdep_rcu_enabled.part.16+0x1a/0x30 > rpc_async_schedule+0x12/0x20 [sunrpc] > process_one_work+0x4d5/0xa70 > ? flush_delayed_work+0x70/0x70 > ? lock_acquire+0xfc/0x220 > worker_thread+0x88/0x630 > ? pci_mmcfg_check_reserved+0xc0/0xc0 > kthread+0x1a6/0x1f0 > ? process_one_work+0xa70/0xa70 > ? kthread_create_on_node+0xc0/0xc0 > ret_from_fork+0x27/0x40 > > Allocated by task 1: > save_stack_trace+0x1b/0x20 > save_stack+0x46/0xd0 > kasan_kmalloc+0xad/0xe0 > kasan_slab_alloc+0x12/0x20 > kmem_cache_alloc+0xe0/0x2f0 > getname_flags+0x43/0x220 > getname+0x12/0x20 > do_sys_open+0x14c/0x2b0 > SyS_open+0x1e/0x20 > do_syscall_64+0xea/0x260 > return_from_SYSCALL_64+0x0/0x7a > > Freed by task 1: > save_stack_trace+0x1b/0x20 > save_stack+0x46/0xd0 > kasan_slab_free+0x72/0xc0 > kmem_cache_free+0xa8/0x300 > putname+0x80/0x90 > do_sys_open+0x22f/0x2b0 > SyS_open+0x1e/0x20 > do_syscall_64+0xea/0x260 > return_from_SYSCALL_64+0x0/0x7a > > The buggy address belongs to the object at 8804508aeac0\x0a which belongs > to the cache names_cache of size 4096 > The buggy address is located 2664 bytes inside of\x0a 4096-byte region > [8804508aeac0, 8804508afac0) > The buggy address belongs to the page: > page:ea0011422a00 count:1 mapcount:0 mapping: (null) index:0x0 > [CONT START] compound_mapcount: 0 > flags: 0x80008100(slab|head) > raw: 80008100 000100070007 > raw: ea00113d6020 ea001136e220 8804664f8040 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > 8804508af400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > 8804508af480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >>8804508af500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ^ > 8804508af580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > 8804508af600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > == >
Re: [PATCH V3] pci: quirk: Apply APM ACS quirk to XGene devices
On Mon, Jul 31, 2017 at 2:55 PM, Alex Williamson wrote: > On Mon, 31 Jul 2017 10:56:53 -0700 > Feng Kan wrote: > >> On Fri, Jul 28, 2017 at 4:00 PM, Alex Williamson >> wrote: >> > On Fri, 28 Jul 2017 11:50:43 -0700 >> > Feng Kan wrote: >> > >> >> The APM X-Gene PCIe root port does not support ACS at this point. >> >> However, the hw provides isolation and source validation through >> >> the SMMU. The stream ID generated by the PCIe ports contain both >> >> the BDF as well as the port ID in its 3 most significant bits. >> >> Turn on ACS but disable all the peer to peer features. >> >> >> >> Signed-off-by: Feng Kan >> >> --- >> >> V3 Change: Add comment regarding unique port id in stream ID >> >> V2 Change: Move XGene ACS quirk to unique XGene function >> >> >> >> drivers/pci/quirks.c | 15 +++ >> >> 1 file changed, 15 insertions(+) >> >> >> >> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c >> >> index 085fb78..0f8f1cd 100644 >> >> --- a/drivers/pci/quirks.c >> >> +++ b/drivers/pci/quirks.c >> >> @@ -4120,6 +4120,19 @@ static int pci_quirk_cavium_acs(struct pci_dev >> >> *dev, u16 acs_flags) >> >> return acs_flags ? 0 : 1; >> >> } >> >> >> >> +static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags) >> >> +{ >> >> + /* >> >> + * XGene root matching this quirk do not allow peer-to-peer >> >> + * transactions with others, allowing masking out these bits as if >> >> they >> >> + * were unimplemented in the ACS capability. >> >> + */ >> >> + acs_flags &= ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR | >> >> +PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT); >> >> + >> >> + return acs_flags ? 0 : 1; >> >> +} >> >> + >> >> /* >> >> * Many Intel PCH root ports do provide ACS-like features to disable peer >> >> * transactions and validate bus numbers in requests, but do not provide >> >> an >> >> @@ -4368,6 +4381,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev >> >> *dev, u16 acs_flags) >> >> { 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */ >> >> /* Cavium ThunderX */ >> >> { PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs }, >> >> + /* APM XGene */ >> >> + { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs }, >> >> { 0 } >> >> }; >> >> >> > >> > Hi Feng, >> > >> > Sorry, I have one more question as I happened to spend some time >> > looking at PCI_ACS_DT this week. DT specifies that peer-to-peer should >> > occur normally between egress ports for transactions which are >> > pre-translated by an ATS unit on the endpoint. Therefore if a root >> > port doesn't allow peer-to-peer, it seems like it should not claim to >> > support PCI_ACS_DT. I know your quirk is just a copy of the Cavium >> > one, but we should also go back and verify this question with them, or >> > perhaps I'm misinterpreting this capability. AIUI this is also a >> > performance capability, not an isolation capability, so it shouldn't >> > affect the ability to consider a device isolated, it only gets >> > confusing if we expect a performance benefit from this but don't >> > actually see one. Does your root port have this ability to >> > selectively allow peer-to-peer of pre-translated transactions? Thanks, >> We do not support peer to peer between root ports (each root port is a >> root complex in itself). >> Therefore, this bit set/unset has no effect. >> >> As one of our guys pointed out in PCIe 3.1a, it may help address your >> concern above. >> >> """ >> Root Port indication of ACS Direct Translated P2P support does not imply any >> particular level of peer-to-peer support by the Root Complex, or that >> peer-to-peer traffic is supported at all. >> """ > > That's interesting, but is that referring to the ACS capability or the > control? I could imagine how advertising the capability would not > imply any particular level of p2p, but enabling the control (which is > what we're claiming via this quirk) the spec states: > > When ACS Direct Translated P2P is enabled in a Downstream Port, > peer-to-peer Memory Requests whose Address Type (AT) field indicates > a Translated address must be routed normally (“directly”) to the peer > Egress Port, regardless of ACS P2P Request Redirect and ACS P2P > Egress Control settings. All other peer-to-peer Requests must still > be subject to ACS P2P Request Redirect and ACS P2P Egress Control > settings. > > Note the *must* phrasing. Furthermore, 7.16.3: > > ACS Direct Translated P2P Enable (T) – When Set, overrides the ACS > P2P Request Redirect and ACS P2P Egress Control mechanisms with > peer-to-peer Memory Requests whose Address Translation (AT) field > indicates a Translated address (see Section 6.12.3). > > This bit is ignored if ACS Translation Blocking Enable (B) is 1b. > > Default value of this bit is 0b. Must be hardwired to 0b if the ACS > Direct Translated P2P functionality is not implemented. > >
Re: [GIT PULL] Please pull NFS client changes for Linux 4.13
On Mon, Jul 31, 2017 at 8:43 AM, da...@codemonkey.org.uk wrote: > Another NFSv4 KASAN splat, this time from rc3. > > BUG: KASAN: use-after-free in nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4] Ugh. It's really hard to tell what access that it - KASAN doesn't actually give enough information. There's lots of 8-byte accesses there in that function. Any chance of getting the output from ./scripts/faddr2line vmlinux nfs4_exchange_id_done+0x3d7/0x8e0 or something? That would be extremely useful in general for stacktraces, but it's doubly useful for KASAN because most *other* stacktraces tend to have a very limited number of things that can warn (ie there's one or two WARN_ON() calls in a function), but KASAN can have tens or hundreds.. Linus > Read of size 8 at addr 8804508af528 by task kworker/2:1/34 > > CPU: 2 PID: 34 Comm: kworker/2:1 Not tainted 4.13.0-rc3-think+ #1 > Workqueue: rpciod rpc_async_schedule [sunrpc] > Call Trace: > dump_stack+0x68/0xa1 > print_address_description+0xd9/0x270 > kasan_report+0x257/0x370 > ? nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4] > check_memory_region+0x13a/0x1a0 > __asan_loadN+0xf/0x20 > nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4] > ? nfs4_exchange_id_release+0xb0/0xb0 [nfsv4] > rpc_exit_task+0x69/0x110 [sunrpc] > ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc] > ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc] > __rpc_execute+0x1a0/0x840 [sunrpc] > ? rpc_wake_up_queued_task+0x50/0x50 [sunrpc] > ? __lock_is_held+0x9a/0x100 > ? debug_lockdep_rcu_enabled.part.16+0x1a/0x30 > rpc_async_schedule+0x12/0x20 [sunrpc] > process_one_work+0x4d5/0xa70 > ? flush_delayed_work+0x70/0x70 > ? lock_acquire+0xfc/0x220 > worker_thread+0x88/0x630 > ? pci_mmcfg_check_reserved+0xc0/0xc0 > kthread+0x1a6/0x1f0 > ? process_one_work+0xa70/0xa70 > ? kthread_create_on_node+0xc0/0xc0 > ret_from_fork+0x27/0x40 > > Allocated by task 1: > save_stack_trace+0x1b/0x20 > save_stack+0x46/0xd0 > kasan_kmalloc+0xad/0xe0 > kasan_slab_alloc+0x12/0x20 > kmem_cache_alloc+0xe0/0x2f0 > getname_flags+0x43/0x220 > getname+0x12/0x20 > do_sys_open+0x14c/0x2b0 > SyS_open+0x1e/0x20 > do_syscall_64+0xea/0x260 > return_from_SYSCALL_64+0x0/0x7a > > Freed by task 1: > save_stack_trace+0x1b/0x20 > save_stack+0x46/0xd0 > kasan_slab_free+0x72/0xc0 > kmem_cache_free+0xa8/0x300 > putname+0x80/0x90 > do_sys_open+0x22f/0x2b0 > SyS_open+0x1e/0x20 > do_syscall_64+0xea/0x260 > return_from_SYSCALL_64+0x0/0x7a > > The buggy address belongs to the object at 8804508aeac0\x0a which belongs > to the cache names_cache of size 4096 > The buggy address is located 2664 bytes inside of\x0a 4096-byte region > [8804508aeac0, 8804508afac0) > The buggy address belongs to the page: > page:ea0011422a00 count:1 mapcount:0 mapping: (null) index:0x0 > [CONT START] compound_mapcount: 0 > flags: 0x80008100(slab|head) > raw: 80008100 000100070007 > raw: ea00113d6020 ea001136e220 8804664f8040 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > 8804508af400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > 8804508af480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >>8804508af500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ^ > 8804508af580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > 8804508af600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > == >
Re: [PATCH v7 08/15] RISC-V: Atomic and Locking Code
On Mon, Jul 31, 2017 at 06:00:02PM -0700, Palmer Dabbelt wrote: > This contains all the code that directly interfaces with the RISC-V > memory model. While this code corforms to the current RISC-V ISA > specifications (user 2.2 and priv 1.10), the memory model is somewhat > underspecified in those documents. There is a working group that hopes > to produce a formal memory model by the end of the year, but my > understanding is that the basic definitions we're relying on here won't > change significantly. > > Signed-off-by: Palmer Dabbelt> --- > arch/riscv/include/asm/atomic.h | 328 > > arch/riscv/include/asm/barrier.h| 68 +++ > arch/riscv/include/asm/bitops.h | 218 + > arch/riscv/include/asm/cacheflush.h | 39 > arch/riscv/include/asm/cmpxchg.h| 134 + > arch/riscv/include/asm/io.h | 303 + > arch/riscv/include/asm/spinlock.h | 165 > arch/riscv/include/asm/spinlock_types.h | 33 > arch/riscv/include/asm/tlb.h| 24 +++ > arch/riscv/include/asm/tlbflush.h | 64 +++ > 10 files changed, 1376 insertions(+) > create mode 100644 arch/riscv/include/asm/atomic.h > create mode 100644 arch/riscv/include/asm/barrier.h > create mode 100644 arch/riscv/include/asm/bitops.h > create mode 100644 arch/riscv/include/asm/cacheflush.h > create mode 100644 arch/riscv/include/asm/cmpxchg.h > create mode 100644 arch/riscv/include/asm/io.h > create mode 100644 arch/riscv/include/asm/spinlock.h > create mode 100644 arch/riscv/include/asm/spinlock_types.h > create mode 100644 arch/riscv/include/asm/tlb.h > create mode 100644 arch/riscv/include/asm/tlbflush.h > > diff --git a/arch/riscv/include/asm/atomic.h b/arch/riscv/include/asm/atomic.h > new file mode 100644 > index ..ee3ab06e492b > --- /dev/null > +++ b/arch/riscv/include/asm/atomic.h > @@ -0,0 +1,328 @@ > +/* > + * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved. > + * Copyright (C) 2012 Regents of the University of California > + * Copyright (C) 2017 SiFive > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public Licence > + * as published by the Free Software Foundation; either version > + * 2 of the Licence, or (at your option) any later version. > + */ > + > +#ifndef _ASM_RISCV_ATOMIC_H > +#define _ASM_RISCV_ATOMIC_H > + > +#ifdef CONFIG_GENERIC_ATOMIC64 > +# include > +#else > +# if (__riscv_xlen < 64) > +# error "64-bit atomics require XLEN to be at least 64" > +# endif > +#endif > + > +#include > +#include > + > +#define ATOMIC_INIT(i) { (i) } > +static __always_inline int atomic_read(const atomic_t *v) > +{ > + return READ_ONCE(v->counter); > +} > +static __always_inline void atomic_set(atomic_t *v, int i) > +{ > + WRITE_ONCE(v->counter, i); > +} > + > +#ifndef CONFIG_GENERIC_ATOMIC64 > +#define ATOMIC64_INIT(i) { (i) } > +static __always_inline int atomic64_read(const atomic64_t *v) ^ should be "long long"? > +{ > + return READ_ONCE(v->counter); > +} > +static __always_inline void atomic64_set(atomic64_t *v, int i) ^ Ditto. Have you ever run the selftest with CONFIG_ATOMIC64_SELFTEST=y? Regards, Boqun > +{ > + WRITE_ONCE(v->counter, i); > +} > +#endif > + [...] signature.asc Description: PGP signature
Re: [PATCH v7 08/15] RISC-V: Atomic and Locking Code
On Mon, Jul 31, 2017 at 06:00:02PM -0700, Palmer Dabbelt wrote: > This contains all the code that directly interfaces with the RISC-V > memory model. While this code corforms to the current RISC-V ISA > specifications (user 2.2 and priv 1.10), the memory model is somewhat > underspecified in those documents. There is a working group that hopes > to produce a formal memory model by the end of the year, but my > understanding is that the basic definitions we're relying on here won't > change significantly. > > Signed-off-by: Palmer Dabbelt > --- > arch/riscv/include/asm/atomic.h | 328 > > arch/riscv/include/asm/barrier.h| 68 +++ > arch/riscv/include/asm/bitops.h | 218 + > arch/riscv/include/asm/cacheflush.h | 39 > arch/riscv/include/asm/cmpxchg.h| 134 + > arch/riscv/include/asm/io.h | 303 + > arch/riscv/include/asm/spinlock.h | 165 > arch/riscv/include/asm/spinlock_types.h | 33 > arch/riscv/include/asm/tlb.h| 24 +++ > arch/riscv/include/asm/tlbflush.h | 64 +++ > 10 files changed, 1376 insertions(+) > create mode 100644 arch/riscv/include/asm/atomic.h > create mode 100644 arch/riscv/include/asm/barrier.h > create mode 100644 arch/riscv/include/asm/bitops.h > create mode 100644 arch/riscv/include/asm/cacheflush.h > create mode 100644 arch/riscv/include/asm/cmpxchg.h > create mode 100644 arch/riscv/include/asm/io.h > create mode 100644 arch/riscv/include/asm/spinlock.h > create mode 100644 arch/riscv/include/asm/spinlock_types.h > create mode 100644 arch/riscv/include/asm/tlb.h > create mode 100644 arch/riscv/include/asm/tlbflush.h > > diff --git a/arch/riscv/include/asm/atomic.h b/arch/riscv/include/asm/atomic.h > new file mode 100644 > index ..ee3ab06e492b > --- /dev/null > +++ b/arch/riscv/include/asm/atomic.h > @@ -0,0 +1,328 @@ > +/* > + * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved. > + * Copyright (C) 2012 Regents of the University of California > + * Copyright (C) 2017 SiFive > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public Licence > + * as published by the Free Software Foundation; either version > + * 2 of the Licence, or (at your option) any later version. > + */ > + > +#ifndef _ASM_RISCV_ATOMIC_H > +#define _ASM_RISCV_ATOMIC_H > + > +#ifdef CONFIG_GENERIC_ATOMIC64 > +# include > +#else > +# if (__riscv_xlen < 64) > +# error "64-bit atomics require XLEN to be at least 64" > +# endif > +#endif > + > +#include > +#include > + > +#define ATOMIC_INIT(i) { (i) } > +static __always_inline int atomic_read(const atomic_t *v) > +{ > + return READ_ONCE(v->counter); > +} > +static __always_inline void atomic_set(atomic_t *v, int i) > +{ > + WRITE_ONCE(v->counter, i); > +} > + > +#ifndef CONFIG_GENERIC_ATOMIC64 > +#define ATOMIC64_INIT(i) { (i) } > +static __always_inline int atomic64_read(const atomic64_t *v) ^ should be "long long"? > +{ > + return READ_ONCE(v->counter); > +} > +static __always_inline void atomic64_set(atomic64_t *v, int i) ^ Ditto. Have you ever run the selftest with CONFIG_ATOMIC64_SELFTEST=y? Regards, Boqun > +{ > + WRITE_ONCE(v->counter, i); > +} > +#endif > + [...] signature.asc Description: PGP signature
Re: [PATCH v2] Bluetooth: btusb: add ID for LiteOn 04ca:3016
Hi Brian, On Mon, Jul 31, 2017, Brian Norris wrote: > Contains a QCA6174A-5 chipset, with USB BT. Let's support loading > firmware on it. > > From usb-devices: > T: Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 > D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=04ca ProdID=3016 Rev=00.01 > C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA > I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > > Signed-off-by: Brian Norris> --- > v2: > * include usb-devices info in commit message > > drivers/bluetooth/btusb.c | 1 + > 1 file changed, 1 insertion(+) Applied to bluetooth-next. Thanks. Johan
Re: [PATCH v2] Bluetooth: btusb: add ID for LiteOn 04ca:3016
Hi Brian, On Mon, Jul 31, 2017, Brian Norris wrote: > Contains a QCA6174A-5 chipset, with USB BT. Let's support loading > firmware on it. > > From usb-devices: > T: Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 > D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=04ca ProdID=3016 Rev=00.01 > C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA > I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > > Signed-off-by: Brian Norris > --- > v2: > * include usb-devices info in commit message > > drivers/bluetooth/btusb.c | 1 + > 1 file changed, 1 insertion(+) Applied to bluetooth-next. Thanks. Johan
linux-next: build failure after merge of the akpm-current tree
Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/kernel/rtas.c: In function 'rtas_online_cpus_mask': arch/powerpc/kernel/rtas.c:917:37: error: 'GFP_KENREL' undeclared (first use in this function) if (!alloc_cpumask_var(_mask, GFP_KENREL)) ^ Caused by commit 404170cf1c4c ("mm: treewide: remove GFP_TEMPORARY allocation flag") I added the following patch: From: Stephen RothwellDate: Tue, 1 Aug 2017 15:25:33 +1000 Subject: [PATCH] mm: treewide: remove GFP_TEMPORARY allocation flag fix Signed-off-by: Stephen Rothwell --- arch/powerpc/kernel/rtas.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c index 90d27dcd0da8..1643e9e53655 100644 --- a/arch/powerpc/kernel/rtas.c +++ b/arch/powerpc/kernel/rtas.c @@ -914,7 +914,7 @@ int rtas_online_cpus_mask(cpumask_var_t cpus) if (ret) { cpumask_var_t tmp_mask; - if (!alloc_cpumask_var(_mask, GFP_KENREL)) + if (!alloc_cpumask_var(_mask, GFP_KERNEL)) return ret; /* Use tmp_mask to preserve cpus mask from first failure */ -- 2.13.2 -- Cheers, Stephen Rothwell
linux-next: build failure after merge of the akpm-current tree
Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/kernel/rtas.c: In function 'rtas_online_cpus_mask': arch/powerpc/kernel/rtas.c:917:37: error: 'GFP_KENREL' undeclared (first use in this function) if (!alloc_cpumask_var(_mask, GFP_KENREL)) ^ Caused by commit 404170cf1c4c ("mm: treewide: remove GFP_TEMPORARY allocation flag") I added the following patch: From: Stephen Rothwell Date: Tue, 1 Aug 2017 15:25:33 +1000 Subject: [PATCH] mm: treewide: remove GFP_TEMPORARY allocation flag fix Signed-off-by: Stephen Rothwell --- arch/powerpc/kernel/rtas.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c index 90d27dcd0da8..1643e9e53655 100644 --- a/arch/powerpc/kernel/rtas.c +++ b/arch/powerpc/kernel/rtas.c @@ -914,7 +914,7 @@ int rtas_online_cpus_mask(cpumask_var_t cpus) if (ret) { cpumask_var_t tmp_mask; - if (!alloc_cpumask_var(_mask, GFP_KENREL)) + if (!alloc_cpumask_var(_mask, GFP_KERNEL)) return ret; /* Use tmp_mask to preserve cpus mask from first failure */ -- 2.13.2 -- Cheers, Stephen Rothwell
RE: Issue with commit de3ef1eb1cd - PM / core: Drop run_wake flag from struct dev_pm_info [Was: MEI-related WARN_ON() triggered during resume-from-sleep on v4.13-rc2+]
Hi We using pci_dev_run_wake that changed in mentioned patch to decide if to replace usual PM callbacks with domain ones. IIRC, the mei device is not remote wakeable on that platform, so we should set domain callbacks. There was a patch in PM framework that squashes runtime suspend with usual suspend for some devices. May it be that now pci_dev_run_wake returns true form mei and we are not setting domain callbacks? In that case we going through PCI device level PM path and may trigger that squash. That will explain lack of mei logs on suspend. Dominik, can you try comment out "if (!pci_dev_run_wake(pdev))" at drivers/misc/mei/pci-me.c (around line 223) to set domain callbacks by force to see if this is indeed the case? -- Alexander (Sasha) Usyskin ISDC TEE CoE – HECI et alii Intel Corporation -Original Message- From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael J. Wysocki Sent: Tuesday, August 01, 2017 03:05 To: Rafael J. WysockiCc: Dominik Brodowski ; Winkler, Tomas ; Wysocki, Rafael J ; Mika Westerberg ; Bjorn Helgaas ; Usyskin, Alexander ; linux-kernel@vger.kernel.org; Linux PM ; ACPI Devel Maling List Subject: Re: Issue with commit de3ef1eb1cd - PM / core: Drop run_wake flag from struct dev_pm_info [Was: MEI-related WARN_ON() triggered during resume-from-sleep on v4.13-rc2+] On Tue, Aug 1, 2017 at 1:55 AM, Rafael J. Wysocki wrote: > Hi, > > On Tue, Aug 1, 2017 at 12:16 AM, Dominik Brodowski > wrote: >> Rafael, Mika, Bjorn and Tomas, >> >> can't explain exactly what causes breakage between MEI and PM first >> seen on >> v4.13-rc2 (ther was a typo in the orignal message), but I was able to >> bisect it down to commit >> >> [de3ef1eb1cd0cc3a75f7a3661e10ed827f370ab8] PM / core: Drop run_wake >> flag from struct dev_pm_info >> > > [cut] > >>> >>> > [ 192.940537] Restarting tasks ... >>> > [ 192.940610] PGI is not set >>> > [ 192.940619] [ cut here ] [ 192.940623] >>> > WARNING: CPU: 0 >>> > PID: 1661 at >>> > /home/brodo/local/kernel/git/linux/drivers/misc/mei/hw- >>> > me.c:653 mei_me_pg_exit_sync+0x351/0x360 [ 192.940624] Modules >>> > linked >>> > in: >>> > [ 192.940627] CPU: 0 PID: 1661 Comm: kworker/0:3 Not tainted >>> > 4.13.0-rc2+ >>> > #2 [ 192.940628] Hardware name: Dell Inc. XPS 13 9343/0TM99H, >>> > BIOS A11 >>> > 12/08/2016 [ 192.940630] Workqueue: pm pm_runtime_work [ >>> > 192.940642] Call Trace: >>> > [ 192.940646] ? pci_pme_active+0x1de/0x1f0 [ 192.940649] ? >>> > pci_restore_standard_config+0x50/0x50 >>> > [ 192.940651] ? kfree+0x172/0x190 [ 192.940653] ? >>> > kfree+0x172/0x190 [ 192.940655] ? >>> > pci_restore_standard_config+0x50/0x50 >>> > [ 192.940663] mei_me_pm_runtime_resume+0x3f/0xc0 >>> > [ 192.940665] pci_pm_runtime_resume+0x7a/0xa0 [ 192.940667] >>> > __rpm_callback+0xb9/0x1e0 [ 192.940668] ? >>> > preempt_count_add+0x6d/0xc0 [ 192.940670] rpm_callback+0x24/0x90 >>> > [ 192.940672] ? pci_restore_standard_config+0x50/0x50 >>> > [ 192.940674] rpm_resume+0x4e8/0x800 [ 192.940676] >>> > pm_runtime_work+0x55/0xb0 [ 192.940678] >>> > process_one_work+0x184/0x3e0 [ 192.940680] >>> > worker_thread+0x4d/0x3a0 [ 192.940681] ? >>> > preempt_count_sub+0x9b/0x100 [ 192.940683] >>> > kthread+0x122/0x140 [ 192.940684] ? process_one_work+0x3e0/0x3e0 >>> > kthread+[ >>> > 192.940685] ? __kthread_create_on_node+0x1a0/0x1a0 >>> > [ 192.940688] ret_from_fork+0x27/0x40 [ 192.940690] Code: 96 3a >>> > 9e ff 48 8b 7d 98 e8 cd 21 58 00 83 bb bc 01 00 00 >>> > 04 0f 85 40 fe ff ff e9 41 fe ff ff 48 c7 c7 5f 04 99 96 e8 93 6b >>> > 9f ff <0f> ff e9 5d fd ff ff e8 33 fe 99 ff 0f 1f 00 0f 1f 44 00 >>> > 00 55 [ 192.940719] ---[ end trace >>> > a86955597774ead8 ]--- [ 192.942540] done. >>> > >>> > This doesn't / didn't happen on v4.12. >> >> >> By using the dynamic_debug infrastructure, I was able to obtain a few >> more data points: >> >> Running 0847684cfc5f, when suspending the system to ram and resuming >> again, I see the following messages: > > You have removed some relevant parts of the log, but I think I see > what's going on. > >> [ 614.936773] sd 3:0:0:0: [sda] Stopping disk >> [ 614.956004] mei_me :00:16.0: rpm: me: runtime resume > > This is a runtime resume during system suspend. > >> [ 614.956165] ACPI : EC: event blocked >> [ 614.980164] mei_me :00:16.0: interrupt source 0x0002 >> [ 614.980191] mei_me :00:16.0: function called after ISR to >> handle the interrupt processing. >> ... >> [ 615.266896] Suspended for 1.190 seconds >> ... >> [ 615.455775] sd 3:0:0:0: [sda] Starting
RE: Issue with commit de3ef1eb1cd - PM / core: Drop run_wake flag from struct dev_pm_info [Was: MEI-related WARN_ON() triggered during resume-from-sleep on v4.13-rc2+]
Hi We using pci_dev_run_wake that changed in mentioned patch to decide if to replace usual PM callbacks with domain ones. IIRC, the mei device is not remote wakeable on that platform, so we should set domain callbacks. There was a patch in PM framework that squashes runtime suspend with usual suspend for some devices. May it be that now pci_dev_run_wake returns true form mei and we are not setting domain callbacks? In that case we going through PCI device level PM path and may trigger that squash. That will explain lack of mei logs on suspend. Dominik, can you try comment out "if (!pci_dev_run_wake(pdev))" at drivers/misc/mei/pci-me.c (around line 223) to set domain callbacks by force to see if this is indeed the case? -- Alexander (Sasha) Usyskin ISDC TEE CoE – HECI et alii Intel Corporation -Original Message- From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael J. Wysocki Sent: Tuesday, August 01, 2017 03:05 To: Rafael J. Wysocki Cc: Dominik Brodowski ; Winkler, Tomas ; Wysocki, Rafael J ; Mika Westerberg ; Bjorn Helgaas ; Usyskin, Alexander ; linux-kernel@vger.kernel.org; Linux PM ; ACPI Devel Maling List Subject: Re: Issue with commit de3ef1eb1cd - PM / core: Drop run_wake flag from struct dev_pm_info [Was: MEI-related WARN_ON() triggered during resume-from-sleep on v4.13-rc2+] On Tue, Aug 1, 2017 at 1:55 AM, Rafael J. Wysocki wrote: > Hi, > > On Tue, Aug 1, 2017 at 12:16 AM, Dominik Brodowski > wrote: >> Rafael, Mika, Bjorn and Tomas, >> >> can't explain exactly what causes breakage between MEI and PM first >> seen on >> v4.13-rc2 (ther was a typo in the orignal message), but I was able to >> bisect it down to commit >> >> [de3ef1eb1cd0cc3a75f7a3661e10ed827f370ab8] PM / core: Drop run_wake >> flag from struct dev_pm_info >> > > [cut] > >>> >>> > [ 192.940537] Restarting tasks ... >>> > [ 192.940610] PGI is not set >>> > [ 192.940619] [ cut here ] [ 192.940623] >>> > WARNING: CPU: 0 >>> > PID: 1661 at >>> > /home/brodo/local/kernel/git/linux/drivers/misc/mei/hw- >>> > me.c:653 mei_me_pg_exit_sync+0x351/0x360 [ 192.940624] Modules >>> > linked >>> > in: >>> > [ 192.940627] CPU: 0 PID: 1661 Comm: kworker/0:3 Not tainted >>> > 4.13.0-rc2+ >>> > #2 [ 192.940628] Hardware name: Dell Inc. XPS 13 9343/0TM99H, >>> > BIOS A11 >>> > 12/08/2016 [ 192.940630] Workqueue: pm pm_runtime_work [ >>> > 192.940642] Call Trace: >>> > [ 192.940646] ? pci_pme_active+0x1de/0x1f0 [ 192.940649] ? >>> > pci_restore_standard_config+0x50/0x50 >>> > [ 192.940651] ? kfree+0x172/0x190 [ 192.940653] ? >>> > kfree+0x172/0x190 [ 192.940655] ? >>> > pci_restore_standard_config+0x50/0x50 >>> > [ 192.940663] mei_me_pm_runtime_resume+0x3f/0xc0 >>> > [ 192.940665] pci_pm_runtime_resume+0x7a/0xa0 [ 192.940667] >>> > __rpm_callback+0xb9/0x1e0 [ 192.940668] ? >>> > preempt_count_add+0x6d/0xc0 [ 192.940670] rpm_callback+0x24/0x90 >>> > [ 192.940672] ? pci_restore_standard_config+0x50/0x50 >>> > [ 192.940674] rpm_resume+0x4e8/0x800 [ 192.940676] >>> > pm_runtime_work+0x55/0xb0 [ 192.940678] >>> > process_one_work+0x184/0x3e0 [ 192.940680] >>> > worker_thread+0x4d/0x3a0 [ 192.940681] ? >>> > preempt_count_sub+0x9b/0x100 [ 192.940683] >>> > kthread+0x122/0x140 [ 192.940684] ? process_one_work+0x3e0/0x3e0 >>> > kthread+[ >>> > 192.940685] ? __kthread_create_on_node+0x1a0/0x1a0 >>> > [ 192.940688] ret_from_fork+0x27/0x40 [ 192.940690] Code: 96 3a >>> > 9e ff 48 8b 7d 98 e8 cd 21 58 00 83 bb bc 01 00 00 >>> > 04 0f 85 40 fe ff ff e9 41 fe ff ff 48 c7 c7 5f 04 99 96 e8 93 6b >>> > 9f ff <0f> ff e9 5d fd ff ff e8 33 fe 99 ff 0f 1f 00 0f 1f 44 00 >>> > 00 55 [ 192.940719] ---[ end trace >>> > a86955597774ead8 ]--- [ 192.942540] done. >>> > >>> > This doesn't / didn't happen on v4.12. >> >> >> By using the dynamic_debug infrastructure, I was able to obtain a few >> more data points: >> >> Running 0847684cfc5f, when suspending the system to ram and resuming >> again, I see the following messages: > > You have removed some relevant parts of the log, but I think I see > what's going on. > >> [ 614.936773] sd 3:0:0:0: [sda] Stopping disk >> [ 614.956004] mei_me :00:16.0: rpm: me: runtime resume > > This is a runtime resume during system suspend. > >> [ 614.956165] ACPI : EC: event blocked >> [ 614.980164] mei_me :00:16.0: interrupt source 0x0002 >> [ 614.980191] mei_me :00:16.0: function called after ISR to >> handle the interrupt processing. >> ... >> [ 615.266896] Suspended for 1.190 seconds >> ... >> [ 615.455775] sd 3:0:0:0: [sda] Starting disk >> [ 615.455855] mei_me :00:16.0: interrupt source 0x0002 >> [ 615.455870] mei_me :00:16.0: function called after ISR to >> handle the interrupt processing. >> [ 615.455877] mei_me :00:16.0: we need to start the dev. >> >> and
linux-next: build warning after merge of the akpm-current tree
Hi Andrew, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: fs/proc/task_mmu.c: In function 'show_map_vma': fs/proc/task_mmu.c:285:28: warning: unused variable 'priv' [-Wunused-variable] struct proc_maps_private *priv = m->private; ^ Introduced by commit 14ccc3193225 ("fs, proc: remove priv argument from is_stack") -- Cheers, Stephen Rothwell
linux-next: build warning after merge of the akpm-current tree
Hi Andrew, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: fs/proc/task_mmu.c: In function 'show_map_vma': fs/proc/task_mmu.c:285:28: warning: unused variable 'priv' [-Wunused-variable] struct proc_maps_private *priv = m->private; ^ Introduced by commit 14ccc3193225 ("fs, proc: remove priv argument from is_stack") -- Cheers, Stephen Rothwell
Re: "BUG: unable to handle kernel NULL pointer dereference" in swapping shmem
Hello Huang, On Tue, Aug 01, 2017 at 11:30:41AM +0800, Huang, Ying wrote: > Hi, Horiguchi san, > > Naoya Horiguchiwrites: > > > Hi, > > > > I found the following bug when testing mmotm-2017-07-31-16-56. > > The triggering testcase just swaps in/out shmem pages. > > It seems to me related to thp swapping improvement patchset, > > so let me report this to the relevant people. > > > > Thanks, > > Naoya Horiguchi > > --- ... > > Thanks for reporting! Do you test it on a HDD? I can reproduce this on > a HDD, the fix patch is as follow, could you try it? Yes, my test ran on a HDD. And I confirmed that the suggested patch fixes the panic. Thank you for your quick work. - Naoya Horiguchi > > Best Regards, > Huang, Ying > > ->8- > From 2487f0230fef59c1ef89792e2af7bcabc02470cf Mon Sep 17 00:00:00 2001 > From: Huang Ying > Date: Tue, 1 Aug 2017 11:20:23 +0800 > Subject: [PATCH] mm, THP, swap: Fix swap_page_trans_huge_swapped on HDD > > To fix the following kernel bug, > > [ 112.690842] ===> testcase 'mm/shmem_swap' start > [ 112.788440] Adding 40956k swap on > /mnt/tests/examples/regression/kernel/mm_regression/mm_regression/work/swapfile. > Priority:-2 extents:1 across:40956k FS > [ 112.815903] bash (17346): drop_caches: 3 > [ 112.975713] BUG: unable to handle kernel NULL pointer dereference at > 0007 > [ 112.984464] IP: swap_page_trans_huge_swapped+0x49/0xd0 > [ 112.990202] PGD 805e62067 > [ 112.990202] P4D 805e62067 > [ 112.993219] PUD 80447b067 > [ 112.996236] PMD 0 > [ 112.999253] > [ 113.003155] Oops: [#1] SMP > [ 113.006658] Modules linked in: nfsv4 dns_resolver nfs fscache > xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 > iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 > xt_conntrack nf_conntrack libcrc32c ipt_REJECT nf_reject_ipv4 tun > bridge stp llc ebtable_filter ebtables ip6_tables iptable_filter > intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm > iTCO_wdt nfsd iTCO_vendor_support mei_me auth_rpcgss mei lpc_ich > ipmi_si ipmi_devintf irqbypass nfs_acl shpchp sg mfd_core ie31200_edac > lockd ipmi_msghandler pcspkr video acpi_pad grace sunrpc ip_tables > sr_mod sd_mod cdrom tg3 ata_generic pata_acpi ata_piix ptp libata > megaraid_sas crc32c_intel pps_core dm_mirror dm_region_hash dm_log > dm_mod > [ 113.077676] CPU: 0 PID: 17431 Comm: test_alloc_gene Not tainted > 4.13.0-rc3-mm1-v4.13-rc3-mmotm-2017-07-31-16-56+ #1 > [ 113.089323] Hardware name: NEC Express5800/T110g-E > [N8100-2187Y]/GA-6LASV1, BIOS 4.6.1204 10/17/2014 > [ 113.099516] task: a06705de9740 task.stack: ac0947c0c000 > [ 113.106124] RIP: 0010:swap_page_trans_huge_swapped+0x49/0xd0 > [ 113.112438] RSP: 0018:ac0947c0fb38 EFLAGS: 00010246 > [ 113.118269] RAX: RBX: RCX: > 0040 > [ 113.126233] RDX: 0001 RSI: 05d6 RDI: > a06705674cfc > [ 113.134196] RBP: ac0947c0fb60 R08: R09: > 88ca2180 > [ 113.142161] R10: 0230 R11: a066e7a9b451 R12: > a06705674c00 > [ 113.150123] R13: 05d6 R14: 0400 R15: > ac0944001000 > [ 113.158088] FS: 7f855b243740() GS:a0672fc0() > knlGS: > [ 113.167118] CS: 0010 DS: ES: CR0: 80050033 > [ 113.173529] CR2: 0007 CR3: 000808de2002 CR4: > 001606f0 > [ 113.181493] Call Trace: > [ 113.184222] free_swap_and_cache+0x73/0x1d0 > [ 113.19] shmem_free_swap+0x5e/0x70 > [ 113.193072] shmem_undo_range+0x4bd/0x8b0 > [ 113.197547] shmem_truncate_range+0x14/0x40 > [ 113.202211] shmem_evict_inode+0xba/0x190 > [ 113.206686] evict+0xd3/0x1a0 > [ 113.210004] iput+0x17d/0x1d0 > [ 113.213316] dentry_unlink_inode+0xb9/0xf0 > [ 113.217887] __dentry_kill+0xc7/0x170 > [ 113.221994] dput+0x19c/0x1d0 > [ 113.225311] __fput+0x188/0x210 > [ 113.228813] fput+0xe/0x10 > [ 113.232221] task_work_run+0x86/0xa0 > [ 113.236209] exit_to_usermode_loop+0x6d/0x99 > [ 113.240981] syscall_return_slowpath+0xad/0xd0 > [ 113.245961] entry_SYSCALL_64_fastpath+0xa3/0xa5 > [ 113.251127] RIP: 0033:0x7f855a940b17 > [ 113.255113] RSP: 002b:7fff955b5048 EFLAGS: 0206 ORIG_RAX: > 001f > [ 113.263562] RAX: RBX: RCX: > 7f855a940b17 > [ 113.271524] RDX: RSI: RDI: > 00028001 > [ 113.279488] RBP: 7fff955b5060 R08: R09: > > [ 113.287450] R10: 7fff955b4dd0 R11: 0206 R12: > 00401da0 > [ 113.295414] R13: 7fff955b5350 R14: R15: > > [ 113.303378] Code: f5 41 54 49 89 fc 53 48 8b 47 70 4c 8b 7f 68 48 85 > c0 74 70 4c 89 f3 48 c1 eb 06 48 01 c3 48 89 df e8 fc 10 54 00 48 85 > db 74 59 43 07 04 75 31 48 b8 ff ff ff ff ff ff ff 01
Re: "BUG: unable to handle kernel NULL pointer dereference" in swapping shmem
Hello Huang, On Tue, Aug 01, 2017 at 11:30:41AM +0800, Huang, Ying wrote: > Hi, Horiguchi san, > > Naoya Horiguchi writes: > > > Hi, > > > > I found the following bug when testing mmotm-2017-07-31-16-56. > > The triggering testcase just swaps in/out shmem pages. > > It seems to me related to thp swapping improvement patchset, > > so let me report this to the relevant people. > > > > Thanks, > > Naoya Horiguchi > > --- ... > > Thanks for reporting! Do you test it on a HDD? I can reproduce this on > a HDD, the fix patch is as follow, could you try it? Yes, my test ran on a HDD. And I confirmed that the suggested patch fixes the panic. Thank you for your quick work. - Naoya Horiguchi > > Best Regards, > Huang, Ying > > ->8- > From 2487f0230fef59c1ef89792e2af7bcabc02470cf Mon Sep 17 00:00:00 2001 > From: Huang Ying > Date: Tue, 1 Aug 2017 11:20:23 +0800 > Subject: [PATCH] mm, THP, swap: Fix swap_page_trans_huge_swapped on HDD > > To fix the following kernel bug, > > [ 112.690842] ===> testcase 'mm/shmem_swap' start > [ 112.788440] Adding 40956k swap on > /mnt/tests/examples/regression/kernel/mm_regression/mm_regression/work/swapfile. > Priority:-2 extents:1 across:40956k FS > [ 112.815903] bash (17346): drop_caches: 3 > [ 112.975713] BUG: unable to handle kernel NULL pointer dereference at > 0007 > [ 112.984464] IP: swap_page_trans_huge_swapped+0x49/0xd0 > [ 112.990202] PGD 805e62067 > [ 112.990202] P4D 805e62067 > [ 112.993219] PUD 80447b067 > [ 112.996236] PMD 0 > [ 112.999253] > [ 113.003155] Oops: [#1] SMP > [ 113.006658] Modules linked in: nfsv4 dns_resolver nfs fscache > xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 > iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 > xt_conntrack nf_conntrack libcrc32c ipt_REJECT nf_reject_ipv4 tun > bridge stp llc ebtable_filter ebtables ip6_tables iptable_filter > intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm > iTCO_wdt nfsd iTCO_vendor_support mei_me auth_rpcgss mei lpc_ich > ipmi_si ipmi_devintf irqbypass nfs_acl shpchp sg mfd_core ie31200_edac > lockd ipmi_msghandler pcspkr video acpi_pad grace sunrpc ip_tables > sr_mod sd_mod cdrom tg3 ata_generic pata_acpi ata_piix ptp libata > megaraid_sas crc32c_intel pps_core dm_mirror dm_region_hash dm_log > dm_mod > [ 113.077676] CPU: 0 PID: 17431 Comm: test_alloc_gene Not tainted > 4.13.0-rc3-mm1-v4.13-rc3-mmotm-2017-07-31-16-56+ #1 > [ 113.089323] Hardware name: NEC Express5800/T110g-E > [N8100-2187Y]/GA-6LASV1, BIOS 4.6.1204 10/17/2014 > [ 113.099516] task: a06705de9740 task.stack: ac0947c0c000 > [ 113.106124] RIP: 0010:swap_page_trans_huge_swapped+0x49/0xd0 > [ 113.112438] RSP: 0018:ac0947c0fb38 EFLAGS: 00010246 > [ 113.118269] RAX: RBX: RCX: > 0040 > [ 113.126233] RDX: 0001 RSI: 05d6 RDI: > a06705674cfc > [ 113.134196] RBP: ac0947c0fb60 R08: R09: > 88ca2180 > [ 113.142161] R10: 0230 R11: a066e7a9b451 R12: > a06705674c00 > [ 113.150123] R13: 05d6 R14: 0400 R15: > ac0944001000 > [ 113.158088] FS: 7f855b243740() GS:a0672fc0() > knlGS: > [ 113.167118] CS: 0010 DS: ES: CR0: 80050033 > [ 113.173529] CR2: 0007 CR3: 000808de2002 CR4: > 001606f0 > [ 113.181493] Call Trace: > [ 113.184222] free_swap_and_cache+0x73/0x1d0 > [ 113.19] shmem_free_swap+0x5e/0x70 > [ 113.193072] shmem_undo_range+0x4bd/0x8b0 > [ 113.197547] shmem_truncate_range+0x14/0x40 > [ 113.202211] shmem_evict_inode+0xba/0x190 > [ 113.206686] evict+0xd3/0x1a0 > [ 113.210004] iput+0x17d/0x1d0 > [ 113.213316] dentry_unlink_inode+0xb9/0xf0 > [ 113.217887] __dentry_kill+0xc7/0x170 > [ 113.221994] dput+0x19c/0x1d0 > [ 113.225311] __fput+0x188/0x210 > [ 113.228813] fput+0xe/0x10 > [ 113.232221] task_work_run+0x86/0xa0 > [ 113.236209] exit_to_usermode_loop+0x6d/0x99 > [ 113.240981] syscall_return_slowpath+0xad/0xd0 > [ 113.245961] entry_SYSCALL_64_fastpath+0xa3/0xa5 > [ 113.251127] RIP: 0033:0x7f855a940b17 > [ 113.255113] RSP: 002b:7fff955b5048 EFLAGS: 0206 ORIG_RAX: > 001f > [ 113.263562] RAX: RBX: RCX: > 7f855a940b17 > [ 113.271524] RDX: RSI: RDI: > 00028001 > [ 113.279488] RBP: 7fff955b5060 R08: R09: > > [ 113.287450] R10: 7fff955b4dd0 R11: 0206 R12: > 00401da0 > [ 113.295414] R13: 7fff955b5350 R14: R15: > > [ 113.303378] Code: f5 41 54 49 89 fc 53 48 8b 47 70 4c 8b 7f 68 48 85 > c0 74 70 4c 89 f3 48 c1 eb 06 48 01 c3 48 89 df e8 fc 10 54 00 48 85 > db 74 59 43 07 04 75 31 48 b8 ff ff ff ff ff ff ff 01 49 21 c5 43 > 80 > [ 113.324450] RIP:
[GIT] Networking
1) Handle notifier registry failures properly in tun/tap driver, from Tonghao Zhang. 2) Fix bpf verifier handling of subtraction bounds and add a testcase for this, from Edward Cree. 3) Increase reset timeout in ftgmac100 driver, from Ben Herrenschmidt. 4) Fix use after free in prd_retire_rx_blk_timer_exired() in AF_PACKET, from Cong Wang. 5) Fix SElinux regression due to recent UDP optimizations, from Paolo Abeni. 6) We accidently increment IPSTATS_MIB_FRAGFAILS in the ipv6 code paths, fix from Stefano Brivio. 7) Fix some mem leaks in dccp, from Xin Long. 8) Adjust MDIO_BUS kconfig deps to avoid build errors, from Arnd Bergmann. 9) Mac address length check and buffer size fixes from Cong Wang. 10) Don't leak sockets in ipv6 udp early demux, from Paolo Abeni. 11) Fix return value when copy_from_user() fails in bpf_prog_get_info_by_fd(), from Daniel Borkmann. 12) Handle PHY_HALTED properly in phy library state machine, from Florian Fainelli. 13) Fix OOPS in fib_sync_down_dev(), from Ido Schimmel. 14) Fix truesize calculation in virtio_net which led to performance regressions, from Michael S. Tsirkin. Please pull, thanks a lot! The following changes since commit 96080f697786e0a30006fcbcc5b53f350fcb3e9f: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-07-20 16:33:39 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git for you to fetch changes up to cc75f8514db6a3aec517760fccaf954e5b46478c: samples/bpf: fix bpf tunnel cleanup (2017-07-31 22:02:47 -0700) Alex Vesker (1): net/mlx5e: IPoIB, Modify add/remove underlay QPN flows Arend Van Spriel (2): brcmfmac: fix regression in brcmf_sdio_txpkt_hdalign() brcmfmac: fix memleak due to calling brcmf_sdiod_sgtable_alloc() twice Arnd Bergmann (3): net: phy: rework Kconfig settings for MDIO_BUS phy: bcm-ns-usb3: fix MDIO_BUS dependency tcp: avoid bogus gcc-7 array-bounds warning Aviv Heller (1): net/mlx5: Consider tx_enabled in all modes on remap Benjamin Herrenschmidt (2): ftgmac100: Increase reset timeout ftgmac100: Make the MDIO bus a child of the ethernet device Colin Ian King (1): net: tc35815: fix spelling mistake: "Intterrupt" -> "Interrupt" Dan Carpenter (1): iwlwifi: missing error code in iwl_trans_pcie_alloc() Daniel Borkmann (2): bpf: don't indicate success when copy_from_user fails bpf: fix bpf_prog_get_info_by_fd to dump correct xlated_prog_len Daniel Stone (1): brcmfmac: Don't grow SKB by negative size David S. Miller (4): Merge branch 'bpf-fix-verifier-min-max-handling-in-BPF_SUB' Merge tag 'wireless-drivers-for-davem-2017-07-21' of git://git.kernel.org/.../kvalo/wireless-drivers Merge tag 'mlx5-fixes-2017-07-27-V2' of git://git.kernel.org/.../saeed/linux Merge tag 'wireless-drivers-for-davem-2017-07-28' of git://git.kernel.org/.../kvalo/wireless-drivers Edward Cree (2): selftests/bpf: subtraction bounds test bpf/verifier: fix min/max handling in BPF_SUB Emmanuel Grumbach (3): iwlwifi: dvm: prevent an out of bounds access iwlwifi: mvm: fix a NULL pointer dereference of error in recovery iwlwifi: fix tracing when tx only is enabled Eran Ben Elisha (1): net/mlx5: Clean SRIOV eswitch resources upon VF creation failure Eugenia Emantayev (7): net/mlx5: Fix mlx5_ifc_mtpps_reg_bits structure size net/mlx5e: Add field select to MTPPS register net/mlx5e: Fix broken disable 1PPS flow net/mlx5e: Change 1PPS out scheme net/mlx5e: Add missing support for PTP_CLK_REQ_PPS request net/mlx5e: Fix wrong delay calculation for overflow check scheduling net/mlx5e: Schedule overflow check work to mlx5e workqueue Florian Fainelli (4): net: dsa: Initialize ds->cpu_port_mask earlier net: phy: Correctly process PHY_HALTED in phy_stop_machine() MAINTAINERS: Add more files to the PHY LIBRARY section Revert "net: bcmgenet: Remove init parameter from bcmgenet_mii_config" Gao Feng (1): ppp: Fix a scheduling-while-atomic bug in del_chan Ido Schimmel (2): mlxsw: spectrum_router: Don't offload routes next in list ipv4: fib: Fix NULL pointer deref during fib_sync_down_dev() Ilan Tayari (1): net/mlx5e: Fix outer_header_zero() check size Jakub Kicinski (1): bpf: don't zero out the info struct in bpf_obj_get_info_by_fd() Jason Wang (1): Revert "vhost: cache used event for better performance" Joel Stanley (1): ftgmac100: return error in ftgmac100_alloc_rx_buf Johannes Berg (1): iwlwifi: mvm: defer setting IWL_MVM_STATUS_IN_HW_RESTART Kalle Valo (1): Merge tag 'iwlwifi-for-kalle-2017-07-21' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes Larry Finger (1): Revert "rtlwifi: btcoex: rtl8723be: fix ant_sel not
[GIT] Networking
1) Handle notifier registry failures properly in tun/tap driver, from Tonghao Zhang. 2) Fix bpf verifier handling of subtraction bounds and add a testcase for this, from Edward Cree. 3) Increase reset timeout in ftgmac100 driver, from Ben Herrenschmidt. 4) Fix use after free in prd_retire_rx_blk_timer_exired() in AF_PACKET, from Cong Wang. 5) Fix SElinux regression due to recent UDP optimizations, from Paolo Abeni. 6) We accidently increment IPSTATS_MIB_FRAGFAILS in the ipv6 code paths, fix from Stefano Brivio. 7) Fix some mem leaks in dccp, from Xin Long. 8) Adjust MDIO_BUS kconfig deps to avoid build errors, from Arnd Bergmann. 9) Mac address length check and buffer size fixes from Cong Wang. 10) Don't leak sockets in ipv6 udp early demux, from Paolo Abeni. 11) Fix return value when copy_from_user() fails in bpf_prog_get_info_by_fd(), from Daniel Borkmann. 12) Handle PHY_HALTED properly in phy library state machine, from Florian Fainelli. 13) Fix OOPS in fib_sync_down_dev(), from Ido Schimmel. 14) Fix truesize calculation in virtio_net which led to performance regressions, from Michael S. Tsirkin. Please pull, thanks a lot! The following changes since commit 96080f697786e0a30006fcbcc5b53f350fcb3e9f: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-07-20 16:33:39 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git for you to fetch changes up to cc75f8514db6a3aec517760fccaf954e5b46478c: samples/bpf: fix bpf tunnel cleanup (2017-07-31 22:02:47 -0700) Alex Vesker (1): net/mlx5e: IPoIB, Modify add/remove underlay QPN flows Arend Van Spriel (2): brcmfmac: fix regression in brcmf_sdio_txpkt_hdalign() brcmfmac: fix memleak due to calling brcmf_sdiod_sgtable_alloc() twice Arnd Bergmann (3): net: phy: rework Kconfig settings for MDIO_BUS phy: bcm-ns-usb3: fix MDIO_BUS dependency tcp: avoid bogus gcc-7 array-bounds warning Aviv Heller (1): net/mlx5: Consider tx_enabled in all modes on remap Benjamin Herrenschmidt (2): ftgmac100: Increase reset timeout ftgmac100: Make the MDIO bus a child of the ethernet device Colin Ian King (1): net: tc35815: fix spelling mistake: "Intterrupt" -> "Interrupt" Dan Carpenter (1): iwlwifi: missing error code in iwl_trans_pcie_alloc() Daniel Borkmann (2): bpf: don't indicate success when copy_from_user fails bpf: fix bpf_prog_get_info_by_fd to dump correct xlated_prog_len Daniel Stone (1): brcmfmac: Don't grow SKB by negative size David S. Miller (4): Merge branch 'bpf-fix-verifier-min-max-handling-in-BPF_SUB' Merge tag 'wireless-drivers-for-davem-2017-07-21' of git://git.kernel.org/.../kvalo/wireless-drivers Merge tag 'mlx5-fixes-2017-07-27-V2' of git://git.kernel.org/.../saeed/linux Merge tag 'wireless-drivers-for-davem-2017-07-28' of git://git.kernel.org/.../kvalo/wireless-drivers Edward Cree (2): selftests/bpf: subtraction bounds test bpf/verifier: fix min/max handling in BPF_SUB Emmanuel Grumbach (3): iwlwifi: dvm: prevent an out of bounds access iwlwifi: mvm: fix a NULL pointer dereference of error in recovery iwlwifi: fix tracing when tx only is enabled Eran Ben Elisha (1): net/mlx5: Clean SRIOV eswitch resources upon VF creation failure Eugenia Emantayev (7): net/mlx5: Fix mlx5_ifc_mtpps_reg_bits structure size net/mlx5e: Add field select to MTPPS register net/mlx5e: Fix broken disable 1PPS flow net/mlx5e: Change 1PPS out scheme net/mlx5e: Add missing support for PTP_CLK_REQ_PPS request net/mlx5e: Fix wrong delay calculation for overflow check scheduling net/mlx5e: Schedule overflow check work to mlx5e workqueue Florian Fainelli (4): net: dsa: Initialize ds->cpu_port_mask earlier net: phy: Correctly process PHY_HALTED in phy_stop_machine() MAINTAINERS: Add more files to the PHY LIBRARY section Revert "net: bcmgenet: Remove init parameter from bcmgenet_mii_config" Gao Feng (1): ppp: Fix a scheduling-while-atomic bug in del_chan Ido Schimmel (2): mlxsw: spectrum_router: Don't offload routes next in list ipv4: fib: Fix NULL pointer deref during fib_sync_down_dev() Ilan Tayari (1): net/mlx5e: Fix outer_header_zero() check size Jakub Kicinski (1): bpf: don't zero out the info struct in bpf_obj_get_info_by_fd() Jason Wang (1): Revert "vhost: cache used event for better performance" Joel Stanley (1): ftgmac100: return error in ftgmac100_alloc_rx_buf Johannes Berg (1): iwlwifi: mvm: defer setting IWL_MVM_STATUS_IN_HW_RESTART Kalle Valo (1): Merge tag 'iwlwifi-for-kalle-2017-07-21' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes Larry Finger (1): Revert "rtlwifi: btcoex: rtl8723be: fix ant_sel not
Re: [PATCH v4 00/15] exec: Use sane stack rlimit under secureexec
On Mon, Jul 31, 2017 at 10:11 PM, Linus Torvaldswrote: > > And I just checked this on a separate branch, just because I wanted to > see what the overall diff was. There's a conflict [..] Side note: the overall patch looks fine to me. I like how it removes complexity and code. I didn't test it (other than test *building* the merge), so take that for what it's worth, but at least the patches look sensible both on an individual level and as an end result. Linus
Re: [PATCH v4 00/15] exec: Use sane stack rlimit under secureexec
On Mon, Jul 31, 2017 at 10:11 PM, Linus Torvalds wrote: > > And I just checked this on a separate branch, just because I wanted to > see what the overall diff was. There's a conflict [..] Side note: the overall patch looks fine to me. I like how it removes complexity and code. I didn't test it (other than test *building* the merge), so take that for what it's worth, but at least the patches look sensible both on an individual level and as an end result. Linus
Re: [PATCH v4 00/15] exec: Use sane stack rlimit under secureexec
On Mon, Jul 31, 2017 at 8:03 PM, Kees Cookwrote: > > Yeah, I'm open to whatever. It's not clear where it should go, but if > you want to take it and Linus doesn't want it "early", that works for > me. Linus, Andrew, thoughts? I'd actually like this to go in separately from all the other security stuff. And I just checked this on a separate branch, just because I wanted to see what the overall diff was. There's a conflict with apparmor already - the resolution looks fairly straightforward, but considering the area this touches, it would probably be good that Kees keeps this branch and verifies things like that. Linus
[PATCH] staging/pi433: Solved some coding style issues in pi433_if.c
From: Rishabh HardasSolved a few coding style issues, used BIT macro to set MINORBITS. Signed-off-by: Rishabh Hardas --- drivers/staging/pi433/pi433_if.c | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c index d9328ce..f10ffc3 100644 --- a/drivers/staging/pi433/pi433_if.c +++ b/drivers/staging/pi433/pi433_if.c @@ -47,18 +47,18 @@ #include #include #include +#include #ifdef CONFIG_COMPAT -#include +#include #endif #include "pi433_if.h" #include "rf69.h" - -#define N_PI433_MINORS (1U << MINORBITS) /*32*//* ... up to 256 */ -#define MAX_MSG_SIZE 900 /* min: FIFO_SIZE! */ -#define MSG_FIFO_SIZE 65536 /* 65536 = 2^16 */ -#define NUM_DIO2 +#define N_PI433_MINORS BIT(MINORBITS) /*32*/ /* ... up to 256 */ +#define MAX_MSG_SIZE 900 /* min: FIFO_SIZE! */ +#define MSG_FIFO_SIZE 65536 /* 65536 = 2^16 */ +#define NUM_DIO2 static dev_t pi433_dev; static DEFINE_IDR(pi433_idr); @@ -66,10 +66,14 @@ static struct class *pi433_class; /* mainly for udev to create /dev/pi433 */ -/* tx config is instance specific - so with each open a new tx config struct is needed */ -/* rx config is device specific - so we have just one rx config, ebedded in device struct */ +/* + * tx config is instance specific + * so with each open a new tx config struct is needed + */ +/* + * rx config is device specific + * so we have just one rx config, ebedded in device struct + */ struct pi433_device { /* device handling related values */ dev_t devt; -- 1.9.1
Re: [PATCH v4 00/15] exec: Use sane stack rlimit under secureexec
On Mon, Jul 31, 2017 at 8:03 PM, Kees Cook wrote: > > Yeah, I'm open to whatever. It's not clear where it should go, but if > you want to take it and Linus doesn't want it "early", that works for > me. Linus, Andrew, thoughts? I'd actually like this to go in separately from all the other security stuff. And I just checked this on a separate branch, just because I wanted to see what the overall diff was. There's a conflict with apparmor already - the resolution looks fairly straightforward, but considering the area this touches, it would probably be good that Kees keeps this branch and verifies things like that. Linus
[PATCH] staging/pi433: Solved some coding style issues in pi433_if.c
From: Rishabh Hardas Solved a few coding style issues, used BIT macro to set MINORBITS. Signed-off-by: Rishabh Hardas --- drivers/staging/pi433/pi433_if.c | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c index d9328ce..f10ffc3 100644 --- a/drivers/staging/pi433/pi433_if.c +++ b/drivers/staging/pi433/pi433_if.c @@ -47,18 +47,18 @@ #include #include #include +#include #ifdef CONFIG_COMPAT -#include +#include #endif #include "pi433_if.h" #include "rf69.h" - -#define N_PI433_MINORS (1U << MINORBITS) /*32*//* ... up to 256 */ -#define MAX_MSG_SIZE 900 /* min: FIFO_SIZE! */ -#define MSG_FIFO_SIZE 65536 /* 65536 = 2^16 */ -#define NUM_DIO2 +#define N_PI433_MINORS BIT(MINORBITS) /*32*/ /* ... up to 256 */ +#define MAX_MSG_SIZE 900 /* min: FIFO_SIZE! */ +#define MSG_FIFO_SIZE 65536 /* 65536 = 2^16 */ +#define NUM_DIO2 static dev_t pi433_dev; static DEFINE_IDR(pi433_idr); @@ -66,10 +66,14 @@ static struct class *pi433_class; /* mainly for udev to create /dev/pi433 */ -/* tx config is instance specific - so with each open a new tx config struct is needed */ -/* rx config is device specific - so we have just one rx config, ebedded in device struct */ +/* + * tx config is instance specific + * so with each open a new tx config struct is needed + */ +/* + * rx config is device specific + * so we have just one rx config, ebedded in device struct + */ struct pi433_device { /* device handling related values */ dev_t devt; -- 1.9.1
Re: [PATCH v2] Coccinelle: Script to remove unnecessary static on local variables
Acked-by: Julia LawallOn Mon, 31 Jul 2017, Gustavo A. R. Silva wrote: > Coccinelle script to remove unnecessary static on local variables when > the variables are not used before update. > > Signed-off-by: Gustavo A. R. Silva > --- > Changes in v2: > Update header and Copyright note. > > scripts/coccinelle/misc/static_unnecessary.cocci | 96 > > 1 file changed, 96 insertions(+) > create mode 100644 scripts/coccinelle/misc/static_unnecessary.cocci > > diff --git a/scripts/coccinelle/misc/static_unnecessary.cocci > b/scripts/coccinelle/misc/static_unnecessary.cocci > new file mode 100644 > index 000..2b10586 > --- /dev/null > +++ b/scripts/coccinelle/misc/static_unnecessary.cocci > @@ -0,0 +1,96 @@ > +/// Drop static on local variable when the variable is not used before > update. > +//# > +//# Removing unnecessary static on local variables reduces the code > +//# size and increases maintainability. > +//# > +//# On the other hand, even though it is rare, be aware that if a > +//# large object is initialized all at once, it might not be wise > +//# to remove the static because that would increase the risk of a > +//# stack overflow. > +/// > +// Confidence: Moderate > +// Copyright: (C) 2017 Julia Lawall, Inria. GPLv2. > +// URL: http://coccinelle.lip6.fr/ > +// Copyright: (C) 2017 Gustavo A. R. Silva. GPLv2. > +// Work supported by a grant from > +// The Linux Foundation's Core Infrastructure Initiative. > +// URL: https://www.coreinfrastructure.org/ > +// Options: --no-includes --include-headers > +// Keywords: static > + > +virtual patch > +virtual context > +virtual org > +virtual report > + > +// > +@bad exists@ > +position p; > +identifier x; > +expression e; > +type T; > +@@ > + > +T x@p; > +... when != x = e > +x = <+...x...+> > + > +@worse exists@ > +position p; > +identifier x; > +type T; > +@@ > + > +T x@p; > +... > + > + > +@modify depends on patch && !context && !org && !report@ > +identifier x; > +expression e; > +type T; > +position p != {bad.p,worse.p}; > +@@ > + > +-static > + T x@p; > + ... when != x > + when strict > +?x = e; > +// > + > + > +// > > + > +@modify_context depends on !patch && (context || org || report) forall@ > +type T; > +identifier x; > +expression e; > +position p != {bad.p,worse.p}; > +position j0; > +@@ > + > +* static > + T x@j0@p; > + ... when != x > + when strict > +?x = e; > + > +// > > + > +@script:python modify_org depends on org@ > +j0 << modify_context.j0; > +@@ > + > +msg = "Unnecessary static on local variable." > +coccilib.org.print_todo(j0[0], msg) > + > +// > > + > +@script:python modify_report depends on report@ > +j0 << modify_context.j0; > +@@ > + > +msg = "Unnecessary static on local variable." > +coccilib.report.print_report(j0[0], msg) > + > -- > 2.5.0 > >
Re: [PATCH v2] Coccinelle: Script to remove unnecessary static on local variables
Acked-by: Julia Lawall On Mon, 31 Jul 2017, Gustavo A. R. Silva wrote: > Coccinelle script to remove unnecessary static on local variables when > the variables are not used before update. > > Signed-off-by: Gustavo A. R. Silva > --- > Changes in v2: > Update header and Copyright note. > > scripts/coccinelle/misc/static_unnecessary.cocci | 96 > > 1 file changed, 96 insertions(+) > create mode 100644 scripts/coccinelle/misc/static_unnecessary.cocci > > diff --git a/scripts/coccinelle/misc/static_unnecessary.cocci > b/scripts/coccinelle/misc/static_unnecessary.cocci > new file mode 100644 > index 000..2b10586 > --- /dev/null > +++ b/scripts/coccinelle/misc/static_unnecessary.cocci > @@ -0,0 +1,96 @@ > +/// Drop static on local variable when the variable is not used before > update. > +//# > +//# Removing unnecessary static on local variables reduces the code > +//# size and increases maintainability. > +//# > +//# On the other hand, even though it is rare, be aware that if a > +//# large object is initialized all at once, it might not be wise > +//# to remove the static because that would increase the risk of a > +//# stack overflow. > +/// > +// Confidence: Moderate > +// Copyright: (C) 2017 Julia Lawall, Inria. GPLv2. > +// URL: http://coccinelle.lip6.fr/ > +// Copyright: (C) 2017 Gustavo A. R. Silva. GPLv2. > +// Work supported by a grant from > +// The Linux Foundation's Core Infrastructure Initiative. > +// URL: https://www.coreinfrastructure.org/ > +// Options: --no-includes --include-headers > +// Keywords: static > + > +virtual patch > +virtual context > +virtual org > +virtual report > + > +// > +@bad exists@ > +position p; > +identifier x; > +expression e; > +type T; > +@@ > + > +T x@p; > +... when != x = e > +x = <+...x...+> > + > +@worse exists@ > +position p; > +identifier x; > +type T; > +@@ > + > +T x@p; > +... > + > + > +@modify depends on patch && !context && !org && !report@ > +identifier x; > +expression e; > +type T; > +position p != {bad.p,worse.p}; > +@@ > + > +-static > + T x@p; > + ... when != x > + when strict > +?x = e; > +// > + > + > +// > > + > +@modify_context depends on !patch && (context || org || report) forall@ > +type T; > +identifier x; > +expression e; > +position p != {bad.p,worse.p}; > +position j0; > +@@ > + > +* static > + T x@j0@p; > + ... when != x > + when strict > +?x = e; > + > +// > > + > +@script:python modify_org depends on org@ > +j0 << modify_context.j0; > +@@ > + > +msg = "Unnecessary static on local variable." > +coccilib.org.print_todo(j0[0], msg) > + > +// > > + > +@script:python modify_report depends on report@ > +j0 << modify_context.j0; > +@@ > + > +msg = "Unnecessary static on local variable." > +coccilib.report.print_report(j0[0], msg) > + > -- > 2.5.0 > >
[PATCH 0/3] drm: Add CRTC-id based ioctls for vblank query/event
Here's an updated series for the proposed new IOCTLs. Major changes since last time: * Leave driver API with 32-bit vblank counts * Use ktime_t instead of struct timespec. * Check for MODESETTING before using modesetting APIs * Ensure vblank is running in new get_sequence ioctl There are other minor changes noted in each patch. Thanks to helpful review from: Daniel VetterMichel Dänzer Ville Syrjälä -keith
[PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]
These provide crtc-id based functions instead of pipe-number, while also offering higher resolution time (ns) and wider frame count (64) as required by the Vulkan API. v2: * Check for DRIVER_MODESET in new crtc-based vblank ioctls Failing to check this will oops the driver. * Ensure vblank interupt is running in crtc_get_sequence ioctl The sequence and timing values are not correct while the interrupt is off, so make sure it's running before asking for them. * Short-circuit get_sequence if the counter is enabled and accurate Steal the idea from the code in wait_vblank to avoid the expense of drm_vblank_get/put * Return active state of crtc in crtc_get_sequence ioctl Might be useful for applications that aren't in charge of modesetting? * Use drm_crtc_vblank_get/put in new crtc-based vblank sequence ioctls Daniel Vetter prefers these over the old drm_vblank_put/get APIs. * Return s64 ns instead of u64 in new sequence event Suggested-by: Daniel VetterSuggested-by: Ville Syrjälä Signed-off-by: Keith Packard --- drivers/gpu/drm/drm_internal.h | 6 ++ drivers/gpu/drm/drm_ioctl.c| 2 + drivers/gpu/drm/drm_vblank.c | 173 + include/drm/drm_vblank.h | 1 + include/uapi/drm/drm.h | 32 5 files changed, 214 insertions(+) diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h index 5cecc974d2f9..b68a193b7907 100644 --- a/drivers/gpu/drm/drm_internal.h +++ b/drivers/gpu/drm/drm_internal.h @@ -65,6 +65,12 @@ int drm_legacy_irq_control(struct drm_device *dev, void *data, int drm_legacy_modeset_ctl(struct drm_device *dev, void *data, struct drm_file *file_priv); +int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data, + struct drm_file *filp); + +int drm_crtc_queue_sequence_ioctl(struct drm_device *dev, void *data, + struct drm_file *filp); + /* drm_auth.c */ int drm_getmagic(struct drm_device *dev, void *data, struct drm_file *file_priv); diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index f1e568176da9..63016cf3e224 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -657,6 +657,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = { DRM_UNLOCKED|DRM_RENDER_ALLOW), DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, drm_syncobj_fd_to_handle_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW), + DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl, DRM_UNLOCKED), + DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE, drm_crtc_queue_sequence_ioctl, DRM_UNLOCKED), }; #define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls ) diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 7e7119a5ada3..69b8c92cdd3a 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -812,6 +812,11 @@ static void send_vblank_event(struct drm_device *dev, e->event.vbl.tv_sec = tv.tv_sec; e->event.vbl.tv_usec = tv.tv_usec; break; + case DRM_EVENT_CRTC_SEQUENCE: + if (seq) + e->event.seq.sequence = seq; + e->event.seq.time_ns = ktime_to_ns(now); + break; } trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, seq); drm_send_event_locked(dev, >base); @@ -1682,3 +1687,171 @@ bool drm_crtc_handle_vblank(struct drm_crtc *crtc) return drm_handle_vblank(crtc->dev, drm_crtc_index(crtc)); } EXPORT_SYMBOL(drm_crtc_handle_vblank); + +/* + * Get crtc VBLANK count. + * + * \param dev DRM device + * \param data user arguement, pointing to a drm_crtc_get_sequence structure. + * \param file_priv drm file private for the user's open file descriptor + */ + +int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data, + struct drm_file *file_priv) +{ + struct drm_crtc *crtc; + struct drm_vblank_crtc *vblank; + int pipe; + struct drm_crtc_get_sequence *get_seq = data; + ktime_t now; + bool vblank_enabled; + int ret; + + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + + if (!dev->irq_enabled) + return -EINVAL; + + crtc = drm_crtc_find(dev, get_seq->crtc_id); + if (!crtc) + return -ENOENT; + + pipe = drm_crtc_index(crtc); + + vblank = >vblank[pipe]; + vblank_enabled = dev->vblank_disable_immediate && READ_ONCE(vblank->enabled); + + if (!vblank_enabled) { + ret = drm_crtc_vblank_get(crtc); + if (ret) { + DRM_DEBUG("crtc %d failed to
[PATCH 1/3] drm: Widen vblank UAPI to 64 bits. Change vblank time to ktime_t [v2]
This modifies the datatypes used by the vblank code to provide both 64 bits of vblank count and switch to using ktime_t for timestamps to increase resolution from microseconds to nanoseconds. The driver interfaces have been left using 32 bits of vblank count; all of the code necessary to widen that value for the user API was already included to handle devices returning fewer than 32-bits. This will provide the necessary datatypes for the Vulkan API. v2: * Re-write wait_vblank ioctl to ABSOLUTE sequence When an application uses the WAIT_VBLANK ioctl with RELATIVE or NEXTONMISS bits set, the target vblank interval is updated within the kernel. We need to write that target back to the ioctl buffer and update the flags bits so that if the wait is interrupted by a signal, when it is re-started, it will target precisely the same vblank count as before. * Leave driver API with 32-bit vblank count Suggested-by: Michel DänzerSuggested-by: Daniel Vetter Signed-off-by: Keith Packard --- drivers/gpu/drm/drm_vblank.c | 186 +-- include/drm/drmP.h | 2 +- include/drm/drm_drv.h| 2 +- include/drm/drm_vblank.h | 16 ++-- 4 files changed, 120 insertions(+), 86 deletions(-) diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 463e4d81fb0d..346601ad698d 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -43,7 +43,7 @@ static bool drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe, - struct timeval *tvblank, bool in_vblank_irq); + ktime_t *tvblank, bool in_vblank_irq); static unsigned int drm_timestamp_precision = 20; /* Default to 20 usecs. */ @@ -64,7 +64,7 @@ MODULE_PARM_DESC(timestamp_monotonic, "Use monotonic timestamps"); static void store_vblank(struct drm_device *dev, unsigned int pipe, u32 vblank_count_inc, -struct timeval *t_vblank, u32 last) +ktime_t t_vblank, u32 last) { struct drm_vblank_crtc *vblank = >vblank[pipe]; @@ -73,7 +73,7 @@ static void store_vblank(struct drm_device *dev, unsigned int pipe, vblank->last = last; write_seqlock(>seqlock); - vblank->time = *t_vblank; + vblank->time = t_vblank; vblank->count += vblank_count_inc; write_sequnlock(>seqlock); } @@ -116,7 +116,7 @@ static void drm_reset_vblank_timestamp(struct drm_device *dev, unsigned int pipe { u32 cur_vblank; bool rc; - struct timeval t_vblank; + ktime_t t_vblank; int count = DRM_TIMESTAMP_MAXRETRIES; spin_lock(>vblank_time_lock); @@ -136,13 +136,13 @@ static void drm_reset_vblank_timestamp(struct drm_device *dev, unsigned int pipe * interrupt and assign 0 for now, to mark the vblanktimestamp as invalid. */ if (!rc) - t_vblank = (struct timeval) {0, 0}; + t_vblank = 0; /* * +1 to make sure user will never see the same * vblank counter value before and after a modeset */ - store_vblank(dev, pipe, 1, _vblank, cur_vblank); + store_vblank(dev, pipe, 1, t_vblank, cur_vblank); spin_unlock(>vblank_time_lock); } @@ -165,7 +165,7 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe, struct drm_vblank_crtc *vblank = >vblank[pipe]; u32 cur_vblank, diff; bool rc; - struct timeval t_vblank; + ktime_t t_vblank; int count = DRM_TIMESTAMP_MAXRETRIES; int framedur_ns = vblank->framedur_ns; @@ -190,11 +190,9 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe, /* trust the hw counter when it's around */ diff = (cur_vblank - vblank->last) & dev->max_vblank_count; } else if (rc && framedur_ns) { - const struct timeval *t_old; - u64 diff_ns; + ktime_t diff_ns; - t_old = >time; - diff_ns = timeval_to_ns(_vblank) - timeval_to_ns(t_old); + diff_ns = t_vblank - vblank->time; /* * Figure out how many vblanks we've missed based @@ -228,7 +226,7 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe, } DRM_DEBUG_VBL("updating vblank count on crtc %u:" - " current=%u, diff=%u, hw=%u hw_last=%u\n", + " current=%llu, diff=%u, hw=%u hw_last=%u\n", pipe, vblank->count, diff, cur_vblank, vblank->last); if (diff == 0) { @@ -243,9 +241,9 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe, * for now, to mark the vblanktimestamp as invalid.
[PATCH 0/3] drm: Add CRTC-id based ioctls for vblank query/event
Here's an updated series for the proposed new IOCTLs. Major changes since last time: * Leave driver API with 32-bit vblank counts * Use ktime_t instead of struct timespec. * Check for MODESETTING before using modesetting APIs * Ensure vblank is running in new get_sequence ioctl There are other minor changes noted in each patch. Thanks to helpful review from: Daniel Vetter Michel Dänzer Ville Syrjälä -keith
[PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]
These provide crtc-id based functions instead of pipe-number, while also offering higher resolution time (ns) and wider frame count (64) as required by the Vulkan API. v2: * Check for DRIVER_MODESET in new crtc-based vblank ioctls Failing to check this will oops the driver. * Ensure vblank interupt is running in crtc_get_sequence ioctl The sequence and timing values are not correct while the interrupt is off, so make sure it's running before asking for them. * Short-circuit get_sequence if the counter is enabled and accurate Steal the idea from the code in wait_vblank to avoid the expense of drm_vblank_get/put * Return active state of crtc in crtc_get_sequence ioctl Might be useful for applications that aren't in charge of modesetting? * Use drm_crtc_vblank_get/put in new crtc-based vblank sequence ioctls Daniel Vetter prefers these over the old drm_vblank_put/get APIs. * Return s64 ns instead of u64 in new sequence event Suggested-by: Daniel Vetter Suggested-by: Ville Syrjälä Signed-off-by: Keith Packard --- drivers/gpu/drm/drm_internal.h | 6 ++ drivers/gpu/drm/drm_ioctl.c| 2 + drivers/gpu/drm/drm_vblank.c | 173 + include/drm/drm_vblank.h | 1 + include/uapi/drm/drm.h | 32 5 files changed, 214 insertions(+) diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h index 5cecc974d2f9..b68a193b7907 100644 --- a/drivers/gpu/drm/drm_internal.h +++ b/drivers/gpu/drm/drm_internal.h @@ -65,6 +65,12 @@ int drm_legacy_irq_control(struct drm_device *dev, void *data, int drm_legacy_modeset_ctl(struct drm_device *dev, void *data, struct drm_file *file_priv); +int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data, + struct drm_file *filp); + +int drm_crtc_queue_sequence_ioctl(struct drm_device *dev, void *data, + struct drm_file *filp); + /* drm_auth.c */ int drm_getmagic(struct drm_device *dev, void *data, struct drm_file *file_priv); diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index f1e568176da9..63016cf3e224 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -657,6 +657,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = { DRM_UNLOCKED|DRM_RENDER_ALLOW), DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, drm_syncobj_fd_to_handle_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW), + DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl, DRM_UNLOCKED), + DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE, drm_crtc_queue_sequence_ioctl, DRM_UNLOCKED), }; #define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls ) diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 7e7119a5ada3..69b8c92cdd3a 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -812,6 +812,11 @@ static void send_vblank_event(struct drm_device *dev, e->event.vbl.tv_sec = tv.tv_sec; e->event.vbl.tv_usec = tv.tv_usec; break; + case DRM_EVENT_CRTC_SEQUENCE: + if (seq) + e->event.seq.sequence = seq; + e->event.seq.time_ns = ktime_to_ns(now); + break; } trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, seq); drm_send_event_locked(dev, >base); @@ -1682,3 +1687,171 @@ bool drm_crtc_handle_vblank(struct drm_crtc *crtc) return drm_handle_vblank(crtc->dev, drm_crtc_index(crtc)); } EXPORT_SYMBOL(drm_crtc_handle_vblank); + +/* + * Get crtc VBLANK count. + * + * \param dev DRM device + * \param data user arguement, pointing to a drm_crtc_get_sequence structure. + * \param file_priv drm file private for the user's open file descriptor + */ + +int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data, + struct drm_file *file_priv) +{ + struct drm_crtc *crtc; + struct drm_vblank_crtc *vblank; + int pipe; + struct drm_crtc_get_sequence *get_seq = data; + ktime_t now; + bool vblank_enabled; + int ret; + + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + + if (!dev->irq_enabled) + return -EINVAL; + + crtc = drm_crtc_find(dev, get_seq->crtc_id); + if (!crtc) + return -ENOENT; + + pipe = drm_crtc_index(crtc); + + vblank = >vblank[pipe]; + vblank_enabled = dev->vblank_disable_immediate && READ_ONCE(vblank->enabled); + + if (!vblank_enabled) { + ret = drm_crtc_vblank_get(crtc); + if (ret) { + DRM_DEBUG("crtc %d failed to acquire vblank counter, %d\n", pipe, ret); +
[PATCH 1/3] drm: Widen vblank UAPI to 64 bits. Change vblank time to ktime_t [v2]
This modifies the datatypes used by the vblank code to provide both 64 bits of vblank count and switch to using ktime_t for timestamps to increase resolution from microseconds to nanoseconds. The driver interfaces have been left using 32 bits of vblank count; all of the code necessary to widen that value for the user API was already included to handle devices returning fewer than 32-bits. This will provide the necessary datatypes for the Vulkan API. v2: * Re-write wait_vblank ioctl to ABSOLUTE sequence When an application uses the WAIT_VBLANK ioctl with RELATIVE or NEXTONMISS bits set, the target vblank interval is updated within the kernel. We need to write that target back to the ioctl buffer and update the flags bits so that if the wait is interrupted by a signal, when it is re-started, it will target precisely the same vblank count as before. * Leave driver API with 32-bit vblank count Suggested-by: Michel Dänzer Suggested-by: Daniel Vetter Signed-off-by: Keith Packard --- drivers/gpu/drm/drm_vblank.c | 186 +-- include/drm/drmP.h | 2 +- include/drm/drm_drv.h| 2 +- include/drm/drm_vblank.h | 16 ++-- 4 files changed, 120 insertions(+), 86 deletions(-) diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 463e4d81fb0d..346601ad698d 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -43,7 +43,7 @@ static bool drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe, - struct timeval *tvblank, bool in_vblank_irq); + ktime_t *tvblank, bool in_vblank_irq); static unsigned int drm_timestamp_precision = 20; /* Default to 20 usecs. */ @@ -64,7 +64,7 @@ MODULE_PARM_DESC(timestamp_monotonic, "Use monotonic timestamps"); static void store_vblank(struct drm_device *dev, unsigned int pipe, u32 vblank_count_inc, -struct timeval *t_vblank, u32 last) +ktime_t t_vblank, u32 last) { struct drm_vblank_crtc *vblank = >vblank[pipe]; @@ -73,7 +73,7 @@ static void store_vblank(struct drm_device *dev, unsigned int pipe, vblank->last = last; write_seqlock(>seqlock); - vblank->time = *t_vblank; + vblank->time = t_vblank; vblank->count += vblank_count_inc; write_sequnlock(>seqlock); } @@ -116,7 +116,7 @@ static void drm_reset_vblank_timestamp(struct drm_device *dev, unsigned int pipe { u32 cur_vblank; bool rc; - struct timeval t_vblank; + ktime_t t_vblank; int count = DRM_TIMESTAMP_MAXRETRIES; spin_lock(>vblank_time_lock); @@ -136,13 +136,13 @@ static void drm_reset_vblank_timestamp(struct drm_device *dev, unsigned int pipe * interrupt and assign 0 for now, to mark the vblanktimestamp as invalid. */ if (!rc) - t_vblank = (struct timeval) {0, 0}; + t_vblank = 0; /* * +1 to make sure user will never see the same * vblank counter value before and after a modeset */ - store_vblank(dev, pipe, 1, _vblank, cur_vblank); + store_vblank(dev, pipe, 1, t_vblank, cur_vblank); spin_unlock(>vblank_time_lock); } @@ -165,7 +165,7 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe, struct drm_vblank_crtc *vblank = >vblank[pipe]; u32 cur_vblank, diff; bool rc; - struct timeval t_vblank; + ktime_t t_vblank; int count = DRM_TIMESTAMP_MAXRETRIES; int framedur_ns = vblank->framedur_ns; @@ -190,11 +190,9 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe, /* trust the hw counter when it's around */ diff = (cur_vblank - vblank->last) & dev->max_vblank_count; } else if (rc && framedur_ns) { - const struct timeval *t_old; - u64 diff_ns; + ktime_t diff_ns; - t_old = >time; - diff_ns = timeval_to_ns(_vblank) - timeval_to_ns(t_old); + diff_ns = t_vblank - vblank->time; /* * Figure out how many vblanks we've missed based @@ -228,7 +226,7 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe, } DRM_DEBUG_VBL("updating vblank count on crtc %u:" - " current=%u, diff=%u, hw=%u hw_last=%u\n", + " current=%llu, diff=%u, hw=%u hw_last=%u\n", pipe, vblank->count, diff, cur_vblank, vblank->last); if (diff == 0) { @@ -243,9 +241,9 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe, * for now, to mark the vblanktimestamp as invalid. */ if (!rc && in_vblank_irq) -
[PATCH 2/3] drm: Reorganize drm_pending_event to support future event types [v2]
Place drm_event_vblank in a new union that includes that and a bare drm_event structure. This will allow new members of that union to be added in the future without changing code related to the existing vbl event type. Assignments to the crtc_id field are now done when the event is allocated, rather than when delievered. This way, delivery doesn't need to have the crtc ID available. v2: * Remove 'dev' argument from create_vblank_event It wasn't being used anyways, and if we need it in the future, we can always get it from crtc->dev. * Check for MODESETTING before looking for crtc in queue_vblank_event UMS drivers will oops if we try to get a crtc, so make sure we're modesetting before we try to find a crtc_id to fill into the event. Signed-off-by: Keith Packard--- drivers/gpu/drm/drm_atomic.c | 7 --- drivers/gpu/drm/drm_plane.c | 2 +- drivers/gpu/drm/drm_vblank.c | 30 ++ drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 ++-- include/drm/drm_vblank.h | 8 +++- 6 files changed, 34 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index c0f336d23f9c..272b83ea9369 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1839,7 +1839,7 @@ int drm_atomic_debugfs_init(struct drm_minor *minor) */ static struct drm_pending_vblank_event *create_vblank_event( - struct drm_device *dev, uint64_t user_data) + struct drm_crtc *crtc, uint64_t user_data) { struct drm_pending_vblank_event *e = NULL; @@ -1849,7 +1849,8 @@ static struct drm_pending_vblank_event *create_vblank_event( e->event.base.type = DRM_EVENT_FLIP_COMPLETE; e->event.base.length = sizeof(e->event); - e->event.user_data = user_data; + e->event.vbl.crtc_id = crtc->base.id; + e->event.vbl.user_data = user_data; return e; } @@ -2052,7 +2053,7 @@ static int prepare_crtc_signaling(struct drm_device *dev, if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT || fence_ptr) { struct drm_pending_vblank_event *e; - e = create_vblank_event(dev, arg->user_data); + e = create_vblank_event(crtc, arg->user_data); if (!e) return -ENOMEM; diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 5dc8c4350602..fe9f31285bc2 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -918,7 +918,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev, } e->event.base.type = DRM_EVENT_FLIP_COMPLETE; e->event.base.length = sizeof(e->event); - e->event.user_data = page_flip->user_data; + e->event.vbl.user_data = page_flip->user_data; ret = drm_event_reserve_init(dev, file_priv, >base, >event.base); if (ret) { kfree(e); diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 346601ad698d..7e7119a5ada3 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -804,14 +804,16 @@ static void send_vblank_event(struct drm_device *dev, { struct timeval tv; - tv = ktime_to_timeval(now); - e->event.sequence = seq; - e->event.tv_sec = tv.tv_sec; - e->event.tv_usec = tv.tv_usec; - - trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, -e->event.sequence); - + switch (e->event.base.type) { + case DRM_EVENT_VBLANK: + case DRM_EVENT_FLIP_COMPLETE: + tv = ktime_to_timeval(now); + e->event.vbl.sequence = seq; + e->event.vbl.tv_sec = tv.tv_sec; + e->event.vbl.tv_usec = tv.tv_usec; + break; + } + trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, seq); drm_send_event_locked(dev, >base); } @@ -863,7 +865,6 @@ void drm_crtc_arm_vblank_event(struct drm_crtc *crtc, e->pipe = pipe; e->sequence = drm_vblank_count(dev, pipe); - e->event.crtc_id = crtc->base.id; list_add_tail(>base.link, >vblank_event_list); } EXPORT_SYMBOL(drm_crtc_arm_vblank_event); @@ -894,7 +895,6 @@ void drm_crtc_send_vblank_event(struct drm_crtc *crtc, now = get_drm_timestamp(); } e->pipe = pipe; - e->event.crtc_id = crtc->base.id; send_vblank_event(dev, e, seq, now); } EXPORT_SYMBOL(drm_crtc_send_vblank_event); @@ -1354,8 +1354,14 @@ static int drm_queue_vblank_event(struct drm_device *dev, unsigned int pipe, e->pipe = pipe; e->event.base.type = DRM_EVENT_VBLANK; - e->event.base.length = sizeof(e->event); -
[PATCH 2/3] drm: Reorganize drm_pending_event to support future event types [v2]
Place drm_event_vblank in a new union that includes that and a bare drm_event structure. This will allow new members of that union to be added in the future without changing code related to the existing vbl event type. Assignments to the crtc_id field are now done when the event is allocated, rather than when delievered. This way, delivery doesn't need to have the crtc ID available. v2: * Remove 'dev' argument from create_vblank_event It wasn't being used anyways, and if we need it in the future, we can always get it from crtc->dev. * Check for MODESETTING before looking for crtc in queue_vblank_event UMS drivers will oops if we try to get a crtc, so make sure we're modesetting before we try to find a crtc_id to fill into the event. Signed-off-by: Keith Packard --- drivers/gpu/drm/drm_atomic.c | 7 --- drivers/gpu/drm/drm_plane.c | 2 +- drivers/gpu/drm/drm_vblank.c | 30 ++ drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 ++-- include/drm/drm_vblank.h | 8 +++- 6 files changed, 34 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index c0f336d23f9c..272b83ea9369 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1839,7 +1839,7 @@ int drm_atomic_debugfs_init(struct drm_minor *minor) */ static struct drm_pending_vblank_event *create_vblank_event( - struct drm_device *dev, uint64_t user_data) + struct drm_crtc *crtc, uint64_t user_data) { struct drm_pending_vblank_event *e = NULL; @@ -1849,7 +1849,8 @@ static struct drm_pending_vblank_event *create_vblank_event( e->event.base.type = DRM_EVENT_FLIP_COMPLETE; e->event.base.length = sizeof(e->event); - e->event.user_data = user_data; + e->event.vbl.crtc_id = crtc->base.id; + e->event.vbl.user_data = user_data; return e; } @@ -2052,7 +2053,7 @@ static int prepare_crtc_signaling(struct drm_device *dev, if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT || fence_ptr) { struct drm_pending_vblank_event *e; - e = create_vblank_event(dev, arg->user_data); + e = create_vblank_event(crtc, arg->user_data); if (!e) return -ENOMEM; diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 5dc8c4350602..fe9f31285bc2 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -918,7 +918,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev, } e->event.base.type = DRM_EVENT_FLIP_COMPLETE; e->event.base.length = sizeof(e->event); - e->event.user_data = page_flip->user_data; + e->event.vbl.user_data = page_flip->user_data; ret = drm_event_reserve_init(dev, file_priv, >base, >event.base); if (ret) { kfree(e); diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 346601ad698d..7e7119a5ada3 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -804,14 +804,16 @@ static void send_vblank_event(struct drm_device *dev, { struct timeval tv; - tv = ktime_to_timeval(now); - e->event.sequence = seq; - e->event.tv_sec = tv.tv_sec; - e->event.tv_usec = tv.tv_usec; - - trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, -e->event.sequence); - + switch (e->event.base.type) { + case DRM_EVENT_VBLANK: + case DRM_EVENT_FLIP_COMPLETE: + tv = ktime_to_timeval(now); + e->event.vbl.sequence = seq; + e->event.vbl.tv_sec = tv.tv_sec; + e->event.vbl.tv_usec = tv.tv_usec; + break; + } + trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, seq); drm_send_event_locked(dev, >base); } @@ -863,7 +865,6 @@ void drm_crtc_arm_vblank_event(struct drm_crtc *crtc, e->pipe = pipe; e->sequence = drm_vblank_count(dev, pipe); - e->event.crtc_id = crtc->base.id; list_add_tail(>base.link, >vblank_event_list); } EXPORT_SYMBOL(drm_crtc_arm_vblank_event); @@ -894,7 +895,6 @@ void drm_crtc_send_vblank_event(struct drm_crtc *crtc, now = get_drm_timestamp(); } e->pipe = pipe; - e->event.crtc_id = crtc->base.id; send_vblank_event(dev, e, seq, now); } EXPORT_SYMBOL(drm_crtc_send_vblank_event); @@ -1354,8 +1354,14 @@ static int drm_queue_vblank_event(struct drm_device *dev, unsigned int pipe, e->pipe = pipe; e->event.base.type = DRM_EVENT_VBLANK; - e->event.base.length = sizeof(e->event); - e->event.user_data =
Re: [alsa-devel] [PATCH v2] ASoC: Intel: Reset hw_ptr on resume trigger
On 2017年08月01日 11:30, Vinod Koul wrote: On Mon, Jul 31, 2017 at 06:47:34PM +0800, Cheng-Yi Chiang wrote: From: "U. Artie Eoff"Reset the hw_ptr before queuing the restore_stream_context work to eradicate a nasty white audio noise on resume. Liam, Jie? This on legacy BYT driver.. Tested-by: Cheng-Yi Chiang Signed-off-by: U. Artie Eoff Signed-off-by: Cheng-Yi Chiang --- sound/soc/intel/baytrail/sst-baytrail-pcm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/soc/intel/baytrail/sst-baytrail-pcm.c b/sound/soc/intel/baytrail/sst-baytrail-pcm.c index 4765ad474544..e0db7070cd42 100644 --- a/sound/soc/intel/baytrail/sst-baytrail-pcm.c +++ b/sound/soc/intel/baytrail/sst-baytrail-pcm.c @@ -187,8 +187,10 @@ static int sst_byt_pcm_trigger(struct snd_pcm_substream *substream, int cmd) sst_byt_stream_start(byt, pcm_data->stream, 0); break; case SNDRV_PCM_TRIGGER_RESUME: - if (pdata->restore_stream == true) + if (pdata->restore_stream == true) { + pcm_data->hw_ptr = 0; Won't this break the hw_ptr and make the resuming won't play from the pausing point of the last suspending? Thanks, ~Keyon schedule_work(_data->work); + } else sst_byt_stream_resume(byt, pcm_data->stream); break; -- 2.12.2
Re: [alsa-devel] [PATCH v2] ASoC: Intel: Reset hw_ptr on resume trigger
On 2017年08月01日 11:30, Vinod Koul wrote: On Mon, Jul 31, 2017 at 06:47:34PM +0800, Cheng-Yi Chiang wrote: From: "U. Artie Eoff" Reset the hw_ptr before queuing the restore_stream_context work to eradicate a nasty white audio noise on resume. Liam, Jie? This on legacy BYT driver.. Tested-by: Cheng-Yi Chiang Signed-off-by: U. Artie Eoff Signed-off-by: Cheng-Yi Chiang --- sound/soc/intel/baytrail/sst-baytrail-pcm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/soc/intel/baytrail/sst-baytrail-pcm.c b/sound/soc/intel/baytrail/sst-baytrail-pcm.c index 4765ad474544..e0db7070cd42 100644 --- a/sound/soc/intel/baytrail/sst-baytrail-pcm.c +++ b/sound/soc/intel/baytrail/sst-baytrail-pcm.c @@ -187,8 +187,10 @@ static int sst_byt_pcm_trigger(struct snd_pcm_substream *substream, int cmd) sst_byt_stream_start(byt, pcm_data->stream, 0); break; case SNDRV_PCM_TRIGGER_RESUME: - if (pdata->restore_stream == true) + if (pdata->restore_stream == true) { + pcm_data->hw_ptr = 0; Won't this break the hw_ptr and make the resuming won't play from the pausing point of the last suspending? Thanks, ~Keyon schedule_work(_data->work); + } else sst_byt_stream_resume(byt, pcm_data->stream); break; -- 2.12.2
[PATCH 3/7] mtd: spi-nor: cadence-quadspi: Add runtime PM support
Add pm_runtime* calls to cadence-quadspi driver. This is required to switch on QSPI power domain on TI 66AK2G SoC during probe. Signed-off-by: Vignesh R--- drivers/mtd/spi-nor/cadence-quadspi.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c index 297c86a2d4a7..1e432916e00b 100644 --- a/drivers/mtd/spi-nor/cadence-quadspi.c +++ b/drivers/mtd/spi-nor/cadence-quadspi.c @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -1219,6 +1220,13 @@ static int cqspi_probe(struct platform_device *pdev) return -ENXIO; } + pm_runtime_enable(>dev); + ret = pm_runtime_get_sync(>dev); + if (ret < 0) { + pm_runtime_put_noidle(>dev); + return ret; + } + ret = clk_prepare_enable(cqspi->clk); if (ret) { dev_err(dev, "Cannot enable QSPI clock.\n"); @@ -1269,6 +1277,9 @@ static int cqspi_remove(struct platform_device *pdev) clk_disable_unprepare(cqspi->clk); + pm_runtime_put_sync(>dev); + pm_runtime_disable(>dev); + return 0; } -- 2.13.3
[PATCH 3/7] mtd: spi-nor: cadence-quadspi: Add runtime PM support
Add pm_runtime* calls to cadence-quadspi driver. This is required to switch on QSPI power domain on TI 66AK2G SoC during probe. Signed-off-by: Vignesh R --- drivers/mtd/spi-nor/cadence-quadspi.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c index 297c86a2d4a7..1e432916e00b 100644 --- a/drivers/mtd/spi-nor/cadence-quadspi.c +++ b/drivers/mtd/spi-nor/cadence-quadspi.c @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -1219,6 +1220,13 @@ static int cqspi_probe(struct platform_device *pdev) return -ENXIO; } + pm_runtime_enable(>dev); + ret = pm_runtime_get_sync(>dev); + if (ret < 0) { + pm_runtime_put_noidle(>dev); + return ret; + } + ret = clk_prepare_enable(cqspi->clk); if (ret) { dev_err(dev, "Cannot enable QSPI clock.\n"); @@ -1269,6 +1277,9 @@ static int cqspi_remove(struct platform_device *pdev) clk_disable_unprepare(cqspi->clk); + pm_runtime_put_sync(>dev); + pm_runtime_disable(>dev); + return 0; } -- 2.13.3
[PATCH 4/7] ARM: dts: keystone-k2g: Add QSPI DT entry
Add DT node for Cadence QSPI IP present in 66AK2G SoC. Signed-off-by: Vignesh R--- arch/arm/boot/dts/keystone-k2g.dtsi | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi index bf4d1fa30840..95327aabfaa4 100644 --- a/arch/arm/boot/dts/keystone-k2g.dtsi +++ b/arch/arm/boot/dts/keystone-k2g.dtsi @@ -168,5 +168,20 @@ #reset-cells = <2>; }; }; + + qspi: qspi@294 { + compatible = "ti,k2g-qspi", "cdns,qspi-nor"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x0294 0x1000>, + <0x2400 0x400>; + interrupts = ; + cdns,fifo-depth = <256>; + cdns,fifo-width = <4>; + cdns,trigger-address = <0x2400>; + clocks = <_clks 0x43 0x0>; + power-domains = <_pds 0x43>; + status = "disabled"; + }; }; }; -- 2.13.3
[PATCH 4/7] ARM: dts: keystone-k2g: Add QSPI DT entry
Add DT node for Cadence QSPI IP present in 66AK2G SoC. Signed-off-by: Vignesh R --- arch/arm/boot/dts/keystone-k2g.dtsi | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi index bf4d1fa30840..95327aabfaa4 100644 --- a/arch/arm/boot/dts/keystone-k2g.dtsi +++ b/arch/arm/boot/dts/keystone-k2g.dtsi @@ -168,5 +168,20 @@ #reset-cells = <2>; }; }; + + qspi: qspi@294 { + compatible = "ti,k2g-qspi", "cdns,qspi-nor"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x0294 0x1000>, + <0x2400 0x400>; + interrupts = ; + cdns,fifo-depth = <256>; + cdns,fifo-width = <4>; + cdns,trigger-address = <0x2400>; + clocks = <_clks 0x43 0x0>; + power-domains = <_pds 0x43>; + status = "disabled"; + }; }; }; -- 2.13.3
[PATCH 1/7] mtd: spi-nor: cadence-quadspi: add a delay in write sequence
As per 66AK2G02 TRM[1] SPRUHY8F section 11.15.5.3 Indirect Access Controller programming sequence, a delay equal to couple QSPI master clock(~5ns) is required after setting CQSPI_REG_INDIRECTWR_START bit and writing data to the flash. Add a new compatible to handle the couple of cycles of delay required in the indirect write sequence, since this delay is specific to TI 66AK2G SoC. [1]http://www.ti.com/lit/ug/spruhy8f/spruhy8f.pdf Signed-off-by: Vignesh R--- Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + drivers/mtd/spi-nor/cadence-quadspi.c | 13 + 2 files changed, 14 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index f248056da24c..fdd511a83511 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -2,6 +2,7 @@ Required properties: - compatible : Should be "cdns,qspi-nor". + Should be "ti,k2g-qspi" for TI 66AK2G platform. - reg : Contains two entries, each of which is a tuple consisting of a physical address and length. The first entry is the address and length of the controller register set. The second entry is the diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c index 53c7d8e0327a..94571590371d 100644 --- a/drivers/mtd/spi-nor/cadence-quadspi.c +++ b/drivers/mtd/spi-nor/cadence-quadspi.c @@ -76,6 +76,7 @@ struct cqspi_st { u32 fifo_depth; u32 fifo_width; u32 trigger_address; + u32 wr_delay; struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT]; }; @@ -608,6 +609,14 @@ static int cqspi_indirect_write_execute(struct spi_nor *nor, reinit_completion(>transfer_complete); writel(CQSPI_REG_INDIRECTWR_START_MASK, reg_base + CQSPI_REG_INDIRECTWR); + /* +* As per 66AK2G02 TRM SPRUHY8F section 11.15.5.3 Indirect Access +* Controller programming sequence, couple of cycles of +* QSPI_REF_CLK delay is required for the above bit to +* be internally synchronized by the QSPI module. Provide 5 +* cycles of delay. +*/ + ndelay(cqspi->wr_delay); while (remaining > 0) { write_bytes = remaining > page_size ? page_size : remaining; @@ -1213,6 +1222,9 @@ static int cqspi_probe(struct platform_device *pdev) } cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk); + if (of_device_is_compatible(dev->of_node, "ti,k2g-qspi")) + cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC, + cqspi->master_ref_clk_hz); ret = devm_request_irq(dev, irq, cqspi_irq_handler, 0, pdev->name, cqspi); @@ -1285,6 +1297,7 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = { static const struct of_device_id cqspi_dt_ids[] = { {.compatible = "cdns,qspi-nor",}, + {.compatible = "ti,k2g-qspi",}, { /* end of table */ } }; -- 2.13.3
[PATCH 1/7] mtd: spi-nor: cadence-quadspi: add a delay in write sequence
As per 66AK2G02 TRM[1] SPRUHY8F section 11.15.5.3 Indirect Access Controller programming sequence, a delay equal to couple QSPI master clock(~5ns) is required after setting CQSPI_REG_INDIRECTWR_START bit and writing data to the flash. Add a new compatible to handle the couple of cycles of delay required in the indirect write sequence, since this delay is specific to TI 66AK2G SoC. [1]http://www.ti.com/lit/ug/spruhy8f/spruhy8f.pdf Signed-off-by: Vignesh R --- Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + drivers/mtd/spi-nor/cadence-quadspi.c | 13 + 2 files changed, 14 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index f248056da24c..fdd511a83511 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -2,6 +2,7 @@ Required properties: - compatible : Should be "cdns,qspi-nor". + Should be "ti,k2g-qspi" for TI 66AK2G platform. - reg : Contains two entries, each of which is a tuple consisting of a physical address and length. The first entry is the address and length of the controller register set. The second entry is the diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c index 53c7d8e0327a..94571590371d 100644 --- a/drivers/mtd/spi-nor/cadence-quadspi.c +++ b/drivers/mtd/spi-nor/cadence-quadspi.c @@ -76,6 +76,7 @@ struct cqspi_st { u32 fifo_depth; u32 fifo_width; u32 trigger_address; + u32 wr_delay; struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT]; }; @@ -608,6 +609,14 @@ static int cqspi_indirect_write_execute(struct spi_nor *nor, reinit_completion(>transfer_complete); writel(CQSPI_REG_INDIRECTWR_START_MASK, reg_base + CQSPI_REG_INDIRECTWR); + /* +* As per 66AK2G02 TRM SPRUHY8F section 11.15.5.3 Indirect Access +* Controller programming sequence, couple of cycles of +* QSPI_REF_CLK delay is required for the above bit to +* be internally synchronized by the QSPI module. Provide 5 +* cycles of delay. +*/ + ndelay(cqspi->wr_delay); while (remaining > 0) { write_bytes = remaining > page_size ? page_size : remaining; @@ -1213,6 +1222,9 @@ static int cqspi_probe(struct platform_device *pdev) } cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk); + if (of_device_is_compatible(dev->of_node, "ti,k2g-qspi")) + cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC, + cqspi->master_ref_clk_hz); ret = devm_request_irq(dev, irq, cqspi_irq_handler, 0, pdev->name, cqspi); @@ -1285,6 +1297,7 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = { static const struct of_device_id cqspi_dt_ids[] = { {.compatible = "cdns,qspi-nor",}, + {.compatible = "ti,k2g-qspi",}, { /* end of table */ } }; -- 2.13.3
[PATCH 5/7] ARM: dts: keystone-k2g-evm: Add QSPI node
66AK2G EVM has a s25fl512s flash connected to QSPI CS0. Add pinmux for QSPI and DT entries for the same. Signed-off-by: Vignesh R--- arch/arm/boot/dts/keystone-k2g-evm.dts | 69 ++ 1 file changed, 69 insertions(+) diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts b/arch/arm/boot/dts/keystone-k2g-evm.dts index 61883cb969d2..55d632977e8f 100644 --- a/arch/arm/boot/dts/keystone-k2g-evm.dts +++ b/arch/arm/boot/dts/keystone-k2g-evm.dts @@ -34,6 +34,18 @@ K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN | MUX_MODE0) /* uart0_txd.uart0_txd */ >; }; + + qspi_pins: pinmux_qspi_pins { + pinctrl-single,pins = < + K2G_CORE_IOPAD(0x1204) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_clk.qspi_clk */ + K2G_CORE_IOPAD(0x1208) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_rclk.qspi_rclk */ + K2G_CORE_IOPAD(0x120c) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d0.qspi_d0 */ + K2G_CORE_IOPAD(0x1210) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d1.qspi_d1 */ + K2G_CORE_IOPAD(0x1214) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d2.qspi_d2 */ + K2G_CORE_IOPAD(0x1218) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d3.qspi_d3 */ + K2G_CORE_IOPAD(0x121c) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_csn0.qspi_csn0 */ + >; + }; }; { @@ -41,3 +53,60 @@ pinctrl-0 = <_pins>; status = "okay"; }; + + { + pinctrl-names = "default"; + pinctrl-0 = <_pins>; + cdns,rclk-en; + status = "okay"; + + flash0: m25p80@0 { + compatible = "s25fl512s", "jedec,spi-nor"; + reg = <0>; + spi-tx-bus-width = <1>; + spi-rx-bus-width = <4>; + spi-max-frequency = <9600>; + #address-cells = <1>; + #size-cells = <1>; + cdns,read-delay = <5>; + cdns,tshsl-ns = <500>; + cdns,tsd2d-ns = <500>; + cdns,tchsh-ns = <119>; + cdns,tslch-ns = <119>; + + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "QSPI.u-boot"; + reg = <0x 0x0010>; + }; + partition@10 { + label = "QSPI.u-boot-env"; + reg = <0x0010 0x0004>; + }; + partition@14 { + label = "QSPI.skern"; + reg = <0x0014 0x004>; + }; + partition@18 { + label = "QSPI.sci-firmware"; + reg = <0x0018 0x004>; + }; + partition@1c { + label = "QSPI.kernel"; + reg = <0x001c 0x080>; + }; + partition@9c { + label = "QSPI.u-boot-spl-os"; + reg = <0x009c 0x004>; + }; + partition@a0 { + label = "QSPI.file-system"; + reg = <0x00a0 0x360>; + }; + }; + }; +}; -- 2.13.3
Re: [PATCH V2 00/12]: spmi: pmic-arb: Support for HW v5 and other fixes
On 2017-07-28 12:40, Kiran Gunda wrote: v2: * [PATCH V2 04/12] spmi: pmic-arb: optimize qpnpint_irq_set_type function Added Stephen's Reviewed-by tag. * [PATCH V2 05/12] spmi: pmic-arb: fix memory allocation for mapping_table Added Fixes tag and Stephen's Reviewed-by tag. * [PATCH V2 02/12] spmi: pmic-arb: rename pa_xx to pmic_arb_xx and other cleanup Added Stephen's Reviewed-by tag. * [PATCH V2 06/12] spmi: pmic-arb: replace the writel_relaxed with __raw_writel Added Fixes tag. * [PATCH V2 03/12] spmi: pmic-arb: clean up pmic_arb_find_apid function Fixed alignement issue and added Stephen's reviewed-by tag. Now all the patches in this series are reviewed and acked by Stephen boyd and are ready for merge. v1: * This patch series add the support for pmic arbiter hardware v5 along with the few bug fixes and code cleanup. * This new series is the combined series of [PATCH V3 0/5]: spmi: pmic-arb: Fixup patches and [PATCH V4 0/4]: spmi: pmic-arb: support for V5 HW and bug fixes, which are being reviewed by Stephen Boyd. * This series depends on the below patch uploaded by Stephen Boyd https://patchwork.kernel.org/patch/9810723/. David Collins (1): spmi: pmic-arb: add support for HW version 5 Fenglin Wu (1): spmi: pmic-arb: Remove checking opc value not less than 0 Kiran Gunda (10): spmi: pmic-arb: remove the read/write access checks spmi: pmic-arb: rename pa_xx to pmic_arb_xx and other cleanup spmi: pmic-arb: clean up pmic_arb_find_apid function spmi: pmic-arb: optimize qpnpint_irq_set_type function spmi: pmic-arb: fix memory allocation for mapping_table spmi: pmic-arb: replace the writel_relaxed with __raw_writel spmi: pmic-arb: return the value instead of passing by pointer spmi: pmic-arb: use irq_chip callback to set spmi irq wakeup capability spmi: pmic-arb: return __iomem pointer instead of offset spmi: pmic-arb: fix a possible null pointer dereference drivers/spmi/spmi-pmic-arb.c | 825 +-- 1 file changed, 481 insertions(+), 344 deletions(-) Hi Greg, Could you please pull this patch series in to your tree? All these patches are reviewed and acked by Stephen boyd.
[PATCH 2/7] mtd: spi-nor: cadence-quadspi: Add support to enable loopback clock circuit
Cadence QSPI IP has a adapted loopback circuit which can be enabled by setting BYPASS field to 0 in READCAPTURE register. It enables use of QSPI return clock to latch the data rather than the internal QSPI reference clock. For high speed operations, adapted loopback circuit using QSPI return clock helps to increase data valid window. Add DT parameter cdns,rclk-en to help enable adapted loopback circuit for boards which do have QSPI return clock provided. This patch also modifies cqspi_readdata_capture() function's bypass parameter to bool to match how its used in the function. Signed-off-by: Vignesh R--- Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 3 +++ drivers/mtd/spi-nor/cadence-quadspi.c | 8 ++-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index fdd511a83511..6cc7d58ce7f6 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -15,6 +15,9 @@ Required properties: Optional properties: - cdns,is-decoded-cs : Flag to indicate whether decoder is used or not. +- cdns,rclk-en : Flag to indicate that QSPI return clock is used to latch + the read data rather than the QSPI clock. Make sure that QSPI return + clock is populated on the board before using this property. Optional subnodes: Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c index 94571590371d..297c86a2d4a7 100644 --- a/drivers/mtd/spi-nor/cadence-quadspi.c +++ b/drivers/mtd/spi-nor/cadence-quadspi.c @@ -75,6 +75,7 @@ struct cqspi_st { boolis_decoded_cs; u32 fifo_depth; u32 fifo_width; + boolrclk_en; u32 trigger_address; u32 wr_delay; struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT]; @@ -784,7 +785,7 @@ static void cqspi_config_baudrate_div(struct cqspi_st *cqspi) } static void cqspi_readdata_capture(struct cqspi_st *cqspi, - const unsigned int bypass, + const bool bypass, const unsigned int delay) { void __iomem *reg_base = cqspi->iobase; @@ -848,7 +849,8 @@ static void cqspi_configure(struct spi_nor *nor) cqspi->sclk = sclk; cqspi_config_baudrate_div(cqspi); cqspi_delay(nor); - cqspi_readdata_capture(cqspi, 1, f_pdata->read_delay); + cqspi_readdata_capture(cqspi, !cqspi->rclk_en, + f_pdata->read_delay); } if (switch_cs || switch_ck) @@ -1045,6 +1047,8 @@ static int cqspi_of_get_pdata(struct platform_device *pdev) return -ENXIO; } + cqspi->rclk_en = of_property_read_bool(np, "cdns,rclk-en"); + return 0; } -- 2.13.3
[PATCH 0/7] K2G: Add QSPI support
This series adds support for Cadence QSPI for 66AK2G SoC. The first three patches enhance the cadence-quadspi driver to support loopback clock and pm_runtime and tweaks for 66AK2G SoC. Remaining patches add DT nodes and enable the driver in defconfig. Tested on 66AK2G GP and ICE boards. Vignesh R (7): mtd: spi-nor: cadence-quadspi: add a delay in write sequence mtd: spi-nor: cadence-quadspi: Add support to enable loopback clock circuit mtd: spi-nor: cadence-quadspi: Add runtime PM support ARM: dts: keystone-k2g: Add QSPI DT entry ARM: dts: keystone-k2g-evm: Add QSPI node ARM: dts: keystone-k2g-ice: Add QSPI node ARM: configs: keystone: Enable Cadence QSPI driver .../devicetree/bindings/mtd/cadence-quadspi.txt| 4 ++ arch/arm/boot/dts/keystone-k2g-evm.dts | 69 ++ arch/arm/boot/dts/keystone-k2g-ice.dts | 69 ++ arch/arm/boot/dts/keystone-k2g.dtsi| 15 + arch/arm/configs/keystone_defconfig| 1 + drivers/mtd/spi-nor/cadence-quadspi.c | 32 +- 6 files changed, 188 insertions(+), 2 deletions(-) -- 2.13.3
[PATCH 5/7] ARM: dts: keystone-k2g-evm: Add QSPI node
66AK2G EVM has a s25fl512s flash connected to QSPI CS0. Add pinmux for QSPI and DT entries for the same. Signed-off-by: Vignesh R --- arch/arm/boot/dts/keystone-k2g-evm.dts | 69 ++ 1 file changed, 69 insertions(+) diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts b/arch/arm/boot/dts/keystone-k2g-evm.dts index 61883cb969d2..55d632977e8f 100644 --- a/arch/arm/boot/dts/keystone-k2g-evm.dts +++ b/arch/arm/boot/dts/keystone-k2g-evm.dts @@ -34,6 +34,18 @@ K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN | MUX_MODE0) /* uart0_txd.uart0_txd */ >; }; + + qspi_pins: pinmux_qspi_pins { + pinctrl-single,pins = < + K2G_CORE_IOPAD(0x1204) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_clk.qspi_clk */ + K2G_CORE_IOPAD(0x1208) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_rclk.qspi_rclk */ + K2G_CORE_IOPAD(0x120c) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d0.qspi_d0 */ + K2G_CORE_IOPAD(0x1210) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d1.qspi_d1 */ + K2G_CORE_IOPAD(0x1214) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d2.qspi_d2 */ + K2G_CORE_IOPAD(0x1218) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d3.qspi_d3 */ + K2G_CORE_IOPAD(0x121c) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_csn0.qspi_csn0 */ + >; + }; }; { @@ -41,3 +53,60 @@ pinctrl-0 = <_pins>; status = "okay"; }; + + { + pinctrl-names = "default"; + pinctrl-0 = <_pins>; + cdns,rclk-en; + status = "okay"; + + flash0: m25p80@0 { + compatible = "s25fl512s", "jedec,spi-nor"; + reg = <0>; + spi-tx-bus-width = <1>; + spi-rx-bus-width = <4>; + spi-max-frequency = <9600>; + #address-cells = <1>; + #size-cells = <1>; + cdns,read-delay = <5>; + cdns,tshsl-ns = <500>; + cdns,tsd2d-ns = <500>; + cdns,tchsh-ns = <119>; + cdns,tslch-ns = <119>; + + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "QSPI.u-boot"; + reg = <0x 0x0010>; + }; + partition@10 { + label = "QSPI.u-boot-env"; + reg = <0x0010 0x0004>; + }; + partition@14 { + label = "QSPI.skern"; + reg = <0x0014 0x004>; + }; + partition@18 { + label = "QSPI.sci-firmware"; + reg = <0x0018 0x004>; + }; + partition@1c { + label = "QSPI.kernel"; + reg = <0x001c 0x080>; + }; + partition@9c { + label = "QSPI.u-boot-spl-os"; + reg = <0x009c 0x004>; + }; + partition@a0 { + label = "QSPI.file-system"; + reg = <0x00a0 0x360>; + }; + }; + }; +}; -- 2.13.3
Re: [PATCH V2 00/12]: spmi: pmic-arb: Support for HW v5 and other fixes
On 2017-07-28 12:40, Kiran Gunda wrote: v2: * [PATCH V2 04/12] spmi: pmic-arb: optimize qpnpint_irq_set_type function Added Stephen's Reviewed-by tag. * [PATCH V2 05/12] spmi: pmic-arb: fix memory allocation for mapping_table Added Fixes tag and Stephen's Reviewed-by tag. * [PATCH V2 02/12] spmi: pmic-arb: rename pa_xx to pmic_arb_xx and other cleanup Added Stephen's Reviewed-by tag. * [PATCH V2 06/12] spmi: pmic-arb: replace the writel_relaxed with __raw_writel Added Fixes tag. * [PATCH V2 03/12] spmi: pmic-arb: clean up pmic_arb_find_apid function Fixed alignement issue and added Stephen's reviewed-by tag. Now all the patches in this series are reviewed and acked by Stephen boyd and are ready for merge. v1: * This patch series add the support for pmic arbiter hardware v5 along with the few bug fixes and code cleanup. * This new series is the combined series of [PATCH V3 0/5]: spmi: pmic-arb: Fixup patches and [PATCH V4 0/4]: spmi: pmic-arb: support for V5 HW and bug fixes, which are being reviewed by Stephen Boyd. * This series depends on the below patch uploaded by Stephen Boyd https://patchwork.kernel.org/patch/9810723/. David Collins (1): spmi: pmic-arb: add support for HW version 5 Fenglin Wu (1): spmi: pmic-arb: Remove checking opc value not less than 0 Kiran Gunda (10): spmi: pmic-arb: remove the read/write access checks spmi: pmic-arb: rename pa_xx to pmic_arb_xx and other cleanup spmi: pmic-arb: clean up pmic_arb_find_apid function spmi: pmic-arb: optimize qpnpint_irq_set_type function spmi: pmic-arb: fix memory allocation for mapping_table spmi: pmic-arb: replace the writel_relaxed with __raw_writel spmi: pmic-arb: return the value instead of passing by pointer spmi: pmic-arb: use irq_chip callback to set spmi irq wakeup capability spmi: pmic-arb: return __iomem pointer instead of offset spmi: pmic-arb: fix a possible null pointer dereference drivers/spmi/spmi-pmic-arb.c | 825 +-- 1 file changed, 481 insertions(+), 344 deletions(-) Hi Greg, Could you please pull this patch series in to your tree? All these patches are reviewed and acked by Stephen boyd.
[PATCH 2/7] mtd: spi-nor: cadence-quadspi: Add support to enable loopback clock circuit
Cadence QSPI IP has a adapted loopback circuit which can be enabled by setting BYPASS field to 0 in READCAPTURE register. It enables use of QSPI return clock to latch the data rather than the internal QSPI reference clock. For high speed operations, adapted loopback circuit using QSPI return clock helps to increase data valid window. Add DT parameter cdns,rclk-en to help enable adapted loopback circuit for boards which do have QSPI return clock provided. This patch also modifies cqspi_readdata_capture() function's bypass parameter to bool to match how its used in the function. Signed-off-by: Vignesh R --- Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 3 +++ drivers/mtd/spi-nor/cadence-quadspi.c | 8 ++-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index fdd511a83511..6cc7d58ce7f6 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -15,6 +15,9 @@ Required properties: Optional properties: - cdns,is-decoded-cs : Flag to indicate whether decoder is used or not. +- cdns,rclk-en : Flag to indicate that QSPI return clock is used to latch + the read data rather than the QSPI clock. Make sure that QSPI return + clock is populated on the board before using this property. Optional subnodes: Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c index 94571590371d..297c86a2d4a7 100644 --- a/drivers/mtd/spi-nor/cadence-quadspi.c +++ b/drivers/mtd/spi-nor/cadence-quadspi.c @@ -75,6 +75,7 @@ struct cqspi_st { boolis_decoded_cs; u32 fifo_depth; u32 fifo_width; + boolrclk_en; u32 trigger_address; u32 wr_delay; struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT]; @@ -784,7 +785,7 @@ static void cqspi_config_baudrate_div(struct cqspi_st *cqspi) } static void cqspi_readdata_capture(struct cqspi_st *cqspi, - const unsigned int bypass, + const bool bypass, const unsigned int delay) { void __iomem *reg_base = cqspi->iobase; @@ -848,7 +849,8 @@ static void cqspi_configure(struct spi_nor *nor) cqspi->sclk = sclk; cqspi_config_baudrate_div(cqspi); cqspi_delay(nor); - cqspi_readdata_capture(cqspi, 1, f_pdata->read_delay); + cqspi_readdata_capture(cqspi, !cqspi->rclk_en, + f_pdata->read_delay); } if (switch_cs || switch_ck) @@ -1045,6 +1047,8 @@ static int cqspi_of_get_pdata(struct platform_device *pdev) return -ENXIO; } + cqspi->rclk_en = of_property_read_bool(np, "cdns,rclk-en"); + return 0; } -- 2.13.3
[PATCH 0/7] K2G: Add QSPI support
This series adds support for Cadence QSPI for 66AK2G SoC. The first three patches enhance the cadence-quadspi driver to support loopback clock and pm_runtime and tweaks for 66AK2G SoC. Remaining patches add DT nodes and enable the driver in defconfig. Tested on 66AK2G GP and ICE boards. Vignesh R (7): mtd: spi-nor: cadence-quadspi: add a delay in write sequence mtd: spi-nor: cadence-quadspi: Add support to enable loopback clock circuit mtd: spi-nor: cadence-quadspi: Add runtime PM support ARM: dts: keystone-k2g: Add QSPI DT entry ARM: dts: keystone-k2g-evm: Add QSPI node ARM: dts: keystone-k2g-ice: Add QSPI node ARM: configs: keystone: Enable Cadence QSPI driver .../devicetree/bindings/mtd/cadence-quadspi.txt| 4 ++ arch/arm/boot/dts/keystone-k2g-evm.dts | 69 ++ arch/arm/boot/dts/keystone-k2g-ice.dts | 69 ++ arch/arm/boot/dts/keystone-k2g.dtsi| 15 + arch/arm/configs/keystone_defconfig| 1 + drivers/mtd/spi-nor/cadence-quadspi.c | 32 +- 6 files changed, 188 insertions(+), 2 deletions(-) -- 2.13.3
[PATCH 6/7] ARM: dts: keystone-k2g-ice: Add QSPI node
66AK2G ICE board has a s25fl256s1 flash connected to QSPI CS0. Add pinmux and DT entries for the same. Signed-off-by: Vignesh R--- arch/arm/boot/dts/keystone-k2g-ice.dts | 69 ++ 1 file changed, 69 insertions(+) diff --git a/arch/arm/boot/dts/keystone-k2g-ice.dts b/arch/arm/boot/dts/keystone-k2g-ice.dts index d820d37b5148..075c3a605c8b 100644 --- a/arch/arm/boot/dts/keystone-k2g-ice.dts +++ b/arch/arm/boot/dts/keystone-k2g-ice.dts @@ -26,6 +26,18 @@ K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN | MUX_MODE0) /* uart0_txd.uart0_txd */ >; }; + + qspi_pins: pinmux_qspi_pins { + pinctrl-single,pins = < + K2G_CORE_IOPAD(0x1204) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_clk.qspi_clk */ + K2G_CORE_IOPAD(0x1208) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_rclk.qspi_rclk */ + K2G_CORE_IOPAD(0x120c) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d0.qspi_d0 */ + K2G_CORE_IOPAD(0x1210) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d1.qspi_d1 */ + K2G_CORE_IOPAD(0x1214) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d2.qspi_d2 */ + K2G_CORE_IOPAD(0x1218) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d3.qspi_d3 */ + K2G_CORE_IOPAD(0x121c) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_csn0.qspi_csn0 */ + >; + }; }; { @@ -33,3 +45,60 @@ pinctrl-0 = <_pins>; status = "okay"; }; + + { + pinctrl-names = "default"; + pinctrl-0 = <_pins>; + cdns,rclk-en; + status = "okay"; + + flash0: m25p80@0 { + compatible = "s25fl256s1", "jedec,spi-nor"; + reg = <0>; + spi-tx-bus-width = <1>; + spi-rx-bus-width = <4>; + spi-max-frequency = <9600>; + #address-cells = <1>; + #size-cells = <1>; + cdns,read-delay = <5>; + cdns,tshsl-ns = <500>; + cdns,tsd2d-ns = <500>; + cdns,tchsh-ns = <119>; + cdns,tslch-ns = <119>; + + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "QSPI.u-boot"; + reg = <0x 0x0010>; + }; + partition@10 { + label = "QSPI.u-boot-env"; + reg = <0x0010 0x0004>; + }; + partition@14 { + label = "QSPI.skern"; + reg = <0x0014 0x004>; + }; + partition@18 { + label = "QSPI.sci-firmware"; + reg = <0x0018 0x004>; + }; + partition@1c { + label = "QSPI.kernel"; + reg = <0x001c 0x080>; + }; + partition@9c { + label = "QSPI.u-boot-spl-os"; + reg = <0x009c 0x004>; + }; + partition@a0 { + label = "QSPI.file-system"; + reg = <0x00a0 0x160>; + }; + }; + }; +}; -- 2.13.3
[PATCH 7/7] ARM: configs: keystone: Enable Cadence QSPI driver
66AK2G SoC has a Cadence QSPI IP. Therefore, enable cadence-quadspi driver as part of keystone_defconfig. Since, QSPI flash can be used to for root filesystem, built it into the kernel instead of module. Signed-off-by: Vignesh R--- arch/arm/configs/keystone_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig index d47ea43d097e..4c8abf3c1ab1 100644 --- a/arch/arm/configs/keystone_defconfig +++ b/arch/arm/configs/keystone_defconfig @@ -124,6 +124,7 @@ CONFIG_MTD_M25P80=y CONFIG_MTD_NAND=y CONFIG_MTD_NAND_DAVINCI=y CONFIG_MTD_SPI_NOR=y +CONFIG_SPI_CADENCE_QUADSPI=y CONFIG_MTD_UBI=y CONFIG_BLK_DEV_LOOP=y CONFIG_SRAM=y -- 2.13.3
[PATCH 6/7] ARM: dts: keystone-k2g-ice: Add QSPI node
66AK2G ICE board has a s25fl256s1 flash connected to QSPI CS0. Add pinmux and DT entries for the same. Signed-off-by: Vignesh R --- arch/arm/boot/dts/keystone-k2g-ice.dts | 69 ++ 1 file changed, 69 insertions(+) diff --git a/arch/arm/boot/dts/keystone-k2g-ice.dts b/arch/arm/boot/dts/keystone-k2g-ice.dts index d820d37b5148..075c3a605c8b 100644 --- a/arch/arm/boot/dts/keystone-k2g-ice.dts +++ b/arch/arm/boot/dts/keystone-k2g-ice.dts @@ -26,6 +26,18 @@ K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN | MUX_MODE0) /* uart0_txd.uart0_txd */ >; }; + + qspi_pins: pinmux_qspi_pins { + pinctrl-single,pins = < + K2G_CORE_IOPAD(0x1204) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_clk.qspi_clk */ + K2G_CORE_IOPAD(0x1208) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_rclk.qspi_rclk */ + K2G_CORE_IOPAD(0x120c) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d0.qspi_d0 */ + K2G_CORE_IOPAD(0x1210) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d1.qspi_d1 */ + K2G_CORE_IOPAD(0x1214) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d2.qspi_d2 */ + K2G_CORE_IOPAD(0x1218) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_d3.qspi_d3 */ + K2G_CORE_IOPAD(0x121c) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* qspi_csn0.qspi_csn0 */ + >; + }; }; { @@ -33,3 +45,60 @@ pinctrl-0 = <_pins>; status = "okay"; }; + + { + pinctrl-names = "default"; + pinctrl-0 = <_pins>; + cdns,rclk-en; + status = "okay"; + + flash0: m25p80@0 { + compatible = "s25fl256s1", "jedec,spi-nor"; + reg = <0>; + spi-tx-bus-width = <1>; + spi-rx-bus-width = <4>; + spi-max-frequency = <9600>; + #address-cells = <1>; + #size-cells = <1>; + cdns,read-delay = <5>; + cdns,tshsl-ns = <500>; + cdns,tsd2d-ns = <500>; + cdns,tchsh-ns = <119>; + cdns,tslch-ns = <119>; + + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "QSPI.u-boot"; + reg = <0x 0x0010>; + }; + partition@10 { + label = "QSPI.u-boot-env"; + reg = <0x0010 0x0004>; + }; + partition@14 { + label = "QSPI.skern"; + reg = <0x0014 0x004>; + }; + partition@18 { + label = "QSPI.sci-firmware"; + reg = <0x0018 0x004>; + }; + partition@1c { + label = "QSPI.kernel"; + reg = <0x001c 0x080>; + }; + partition@9c { + label = "QSPI.u-boot-spl-os"; + reg = <0x009c 0x004>; + }; + partition@a0 { + label = "QSPI.file-system"; + reg = <0x00a0 0x160>; + }; + }; + }; +}; -- 2.13.3
[PATCH 7/7] ARM: configs: keystone: Enable Cadence QSPI driver
66AK2G SoC has a Cadence QSPI IP. Therefore, enable cadence-quadspi driver as part of keystone_defconfig. Since, QSPI flash can be used to for root filesystem, built it into the kernel instead of module. Signed-off-by: Vignesh R --- arch/arm/configs/keystone_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig index d47ea43d097e..4c8abf3c1ab1 100644 --- a/arch/arm/configs/keystone_defconfig +++ b/arch/arm/configs/keystone_defconfig @@ -124,6 +124,7 @@ CONFIG_MTD_M25P80=y CONFIG_MTD_NAND=y CONFIG_MTD_NAND_DAVINCI=y CONFIG_MTD_SPI_NOR=y +CONFIG_SPI_CADENCE_QUADSPI=y CONFIG_MTD_UBI=y CONFIG_BLK_DEV_LOOP=y CONFIG_SRAM=y -- 2.13.3
[PATCH 2/6] dt-bindings: ti,omap-hsmmc: Add 66AK2G mmc controller
Update the ti,omap-hsmmc.txt to include information about 66AK2G specific mmc controller. Also cleanup the entries under optional properties to look a bit nicer. Signed-off-by: Lokesh Vutla--- .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 52 +++--- 1 file changed, 37 insertions(+), 15 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 0e026c151c1c..016741402e37 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -1,33 +1,55 @@ -* TI Highspeed MMC host controller for OMAP +* TI Highspeed MMC host controller for OMAP and 66AK2G family. -The Highspeed MMC Host Controller on TI OMAP family +The Highspeed MMC Host Controller on TI OMAP and 66AK2G family provides an interface for MMC, SD, and SDIO types of memory cards. This file documents differences between the core properties described by mmc.txt and the properties used by the omap_hsmmc driver. Required properties: + - compatible: Should be "ti,omap2-hsmmc", for OMAP2 controllers Should be "ti,omap3-hsmmc", for OMAP3 controllers Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0 Should be "ti,omap4-hsmmc", for OMAP4 controllers Should be "ti,am33xx-hsmmc", for AM335x controllers -- ti,hwmods: Must be "mmc", n is controller instance starting 1 + Should be "ti,k2g-hsmmc", "ti,omap4-hsmmc" for 66AK2G controllers. + +SoC specific required properties: +- +The following are mandatory properties for OMAPs, AM33xx and AM43xx SoCs only: +- ti,hwmods: Must be "mmc", n is controller instance starting 1. + +The following are mandatory properties for 66AK2G SoCs only: +- power-domains:Should contain a phandle to a PM domain provider node + and an args specifier containing the MMC device id + value. This property is as per the binding, + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt +- clocks: Must contain an entry for each entry in clock-names. Should + be defined as per the he appropriate clock bindings consumer + usage in Documentation/devicetree/bindings/clock/ti,sci-clk.txt +- clock-names: Shall be "fck" for the functional clock, + and "mmchsdb_fck" for the debounce clock. + Optional properties: -ti,dual-volt: boolean, supports dual voltage cards --supply: phandle to the regulator device tree node -"supply-name" examples are "vmmc", "vmmc_aux"(deprecated)/"vqmmc" etc -ti,non-removable: non-removable slot (like eMMC) -ti,needs-special-reset: Requires a special softreset sequence -ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High Speed -dmas: List of DMA specifiers with the controller specific format -as described in the generic DMA client binding. A tx and rx -specifier is required. -dma-names: List of DMA request names. These strings correspond -1:1 with the DMA specifiers listed in dmas. The string naming is -to be "rx" and "tx" for RX and TX DMA requests, respectively. + +- ti,dual-volt:boolean, supports dual voltage cards +- -supply:phandle to the regulator device tree node + "supply-name" examples are "vmmc", + "vmmc_aux"(deprecated)/"vqmmc" etc +- ti,non-removable:non-removable slot (like eMMC) +- ti,needs-special-reset: Requires a special softreset sequence +- ti,needs-special-hs-handling:HSMMC IP needs special setting + for handling High Speed +- dmas:List of DMA specifiers with the controller specific + format as described in the generic DMA client + binding. A tx and rx specifier is required. +- dma-names: List of DMA request names. These strings correspond + 1:1 with the DMA specifiers listed in dmas. + The string naming is to be "rx" and "tx" for + RX and TX DMA requests, respectively. Examples: -- 2.13.0
[PATCH 2/6] dt-bindings: ti,omap-hsmmc: Add 66AK2G mmc controller
Update the ti,omap-hsmmc.txt to include information about 66AK2G specific mmc controller. Also cleanup the entries under optional properties to look a bit nicer. Signed-off-by: Lokesh Vutla --- .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 52 +++--- 1 file changed, 37 insertions(+), 15 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 0e026c151c1c..016741402e37 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -1,33 +1,55 @@ -* TI Highspeed MMC host controller for OMAP +* TI Highspeed MMC host controller for OMAP and 66AK2G family. -The Highspeed MMC Host Controller on TI OMAP family +The Highspeed MMC Host Controller on TI OMAP and 66AK2G family provides an interface for MMC, SD, and SDIO types of memory cards. This file documents differences between the core properties described by mmc.txt and the properties used by the omap_hsmmc driver. Required properties: + - compatible: Should be "ti,omap2-hsmmc", for OMAP2 controllers Should be "ti,omap3-hsmmc", for OMAP3 controllers Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0 Should be "ti,omap4-hsmmc", for OMAP4 controllers Should be "ti,am33xx-hsmmc", for AM335x controllers -- ti,hwmods: Must be "mmc", n is controller instance starting 1 + Should be "ti,k2g-hsmmc", "ti,omap4-hsmmc" for 66AK2G controllers. + +SoC specific required properties: +- +The following are mandatory properties for OMAPs, AM33xx and AM43xx SoCs only: +- ti,hwmods: Must be "mmc", n is controller instance starting 1. + +The following are mandatory properties for 66AK2G SoCs only: +- power-domains:Should contain a phandle to a PM domain provider node + and an args specifier containing the MMC device id + value. This property is as per the binding, + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt +- clocks: Must contain an entry for each entry in clock-names. Should + be defined as per the he appropriate clock bindings consumer + usage in Documentation/devicetree/bindings/clock/ti,sci-clk.txt +- clock-names: Shall be "fck" for the functional clock, + and "mmchsdb_fck" for the debounce clock. + Optional properties: -ti,dual-volt: boolean, supports dual voltage cards --supply: phandle to the regulator device tree node -"supply-name" examples are "vmmc", "vmmc_aux"(deprecated)/"vqmmc" etc -ti,non-removable: non-removable slot (like eMMC) -ti,needs-special-reset: Requires a special softreset sequence -ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High Speed -dmas: List of DMA specifiers with the controller specific format -as described in the generic DMA client binding. A tx and rx -specifier is required. -dma-names: List of DMA request names. These strings correspond -1:1 with the DMA specifiers listed in dmas. The string naming is -to be "rx" and "tx" for RX and TX DMA requests, respectively. + +- ti,dual-volt:boolean, supports dual voltage cards +- -supply:phandle to the regulator device tree node + "supply-name" examples are "vmmc", + "vmmc_aux"(deprecated)/"vqmmc" etc +- ti,non-removable:non-removable slot (like eMMC) +- ti,needs-special-reset: Requires a special softreset sequence +- ti,needs-special-hs-handling:HSMMC IP needs special setting + for handling High Speed +- dmas:List of DMA specifiers with the controller specific + format as described in the generic DMA client + binding. A tx and rx specifier is required. +- dma-names: List of DMA request names. These strings correspond + 1:1 with the DMA specifiers listed in dmas. + The string naming is to be "rx" and "tx" for + RX and TX DMA requests, respectively. Examples: -- 2.13.0
[PATCH 6/6] ARM: configs: keystone: Enable MMC and regulators
Enable the TI OMAP HSMMC and fixed regulator support for keystone platforms. Signed-off-by: Lokesh Vutla--- arch/arm/configs/keystone_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig index d47ea43d097e..3397e91a5db1 100644 --- a/arch/arm/configs/keystone_defconfig +++ b/arch/arm/configs/keystone_defconfig @@ -156,6 +156,8 @@ CONFIG_POWER_RESET_KEYSTONE=y # CONFIG_HWMON is not set CONFIG_WATCHDOG=y CONFIG_DAVINCI_WATCHDOG=y +CONFIG_REGULATOR=y +CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_MON=y @@ -164,6 +166,8 @@ CONFIG_USB_STORAGE=y CONFIG_USB_DWC3=y CONFIG_NOP_USB_XCEIV=y CONFIG_KEYSTONE_USB_PHY=y +CONFIG_MMC=y +CONFIG_MMC_OMAP_HS=y CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y CONFIG_LEDS_GPIO=y -- 2.13.0
[PATCH 6/6] ARM: configs: keystone: Enable MMC and regulators
Enable the TI OMAP HSMMC and fixed regulator support for keystone platforms. Signed-off-by: Lokesh Vutla --- arch/arm/configs/keystone_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig index d47ea43d097e..3397e91a5db1 100644 --- a/arch/arm/configs/keystone_defconfig +++ b/arch/arm/configs/keystone_defconfig @@ -156,6 +156,8 @@ CONFIG_POWER_RESET_KEYSTONE=y # CONFIG_HWMON is not set CONFIG_WATCHDOG=y CONFIG_DAVINCI_WATCHDOG=y +CONFIG_REGULATOR=y +CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_MON=y @@ -164,6 +166,8 @@ CONFIG_USB_STORAGE=y CONFIG_USB_DWC3=y CONFIG_NOP_USB_XCEIV=y CONFIG_KEYSTONE_USB_PHY=y +CONFIG_MMC=y +CONFIG_MMC_OMAP_HS=y CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y CONFIG_LEDS_GPIO=y -- 2.13.0
[PATCH 0/6] ARM: dts: keystone-k2g: Add support for eDMA and MMC
This series adds DT nodes and documentation for eDMA and MMC IPs on Keystone 66AK2G SoC. Also enable the required configs in keystone_defconfig. This series depends on Keerthy's gpio node patches on 66AK2G: https://patchwork.kernel.org/patch/9864311/ Tested: k2g-evm with rootfs on mmc: http://pastebin.ubuntu.com/25217978/ Lokesh Vutla (5): dt-bindings: ti,edma: Add 66AK2G specific information dt-bindings: ti,omap-hsmmc: Add 66AK2G mmc controller ARM: dts: keystone-k2g: add MMC0 and MMC1 nodes ARM: dts: keystone-k2g-evm: Enable MMC0 and MMC1 ARM: configs: keystone: Enable MMC and regulators Peter Ujfalusi (1): ARM: dts: keystone-k2g: Add eDMA nodes Documentation/devicetree/bindings/dma/ti-edma.txt | 95 +++-- .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 52 arch/arm/boot/dts/keystone-k2g-evm.dts | 53 arch/arm/boot/dts/keystone-k2g.dtsi| 98 ++ arch/arm/configs/keystone_defconfig| 4 + 5 files changed, 282 insertions(+), 20 deletions(-) -- 2.13.0
[PATCH 5/6] ARM: dts: keystone-k2g-evm: Enable MMC0 and MMC1
Enable MMC0 which is used for micro SD and MMC1 which is used for the on board EMMC. Signed-off-by: Lokesh Vutla[fcoo...@ti.com: add mmc1, bufferclass and pullup/pulldown settings] Signed-off-by: Franklin S Cooper Jr [nsek...@ti.com: add card detect GPIO support] Signed-off-by: Sekhar Nori --- arch/arm/boot/dts/keystone-k2g-evm.dts | 53 ++ 1 file changed, 53 insertions(+) diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts b/arch/arm/boot/dts/keystone-k2g-evm.dts index 61883cb969d2..f47f95d8bf1c 100644 --- a/arch/arm/boot/dts/keystone-k2g-evm.dts +++ b/arch/arm/boot/dts/keystone-k2g-evm.dts @@ -25,6 +25,13 @@ reg = <0x0008 0x 0x 0x8000>; }; + vcc3v3_dcin_reg: fixedregulator-vcc3v3-dcin { + compatible = "regulator-fixed"; + regulator-name = "mmc0_fixed"; + regulator-min-microvolt = <330>; + regulator-max-microvolt = <330>; + regulator-always-on; + }; }; _pinctrl { @@ -34,6 +41,33 @@ K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN | MUX_MODE0) /* uart0_txd.uart0_txd */ >; }; + + mmc0_pins: pinmux_mmc0_pins { + pinctrl-single,pins = < + K2G_CORE_IOPAD(0x1300) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE2)/* mmc0_dat3.mmc0_dat3 */ + K2G_CORE_IOPAD(0x1304) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE2)/* mmc0_dat2.mmc0_dat2 */ + K2G_CORE_IOPAD(0x1308) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE2)/* mmc0_dat1.mmc0_dat1 */ + K2G_CORE_IOPAD(0x130c) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE2)/* mmc0_dat0.mmc0_dat0 */ + K2G_CORE_IOPAD(0x1310) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE2)/* mmc0_clk.mmc0_clk */ + K2G_CORE_IOPAD(0x1314) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE2)/* mmc0_cmd.mmc0_cmd */ + K2G_CORE_IOPAD(0x12ec) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE3)/* mmc0_sdcd.gpio1_12 */ + >; + }; + + mmc1_pins: pinmux_mmc1_pins { + pinctrl-single,pins = < + K2G_CORE_IOPAD(0x10ec) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_dat7.mmc1_dat7 */ + K2G_CORE_IOPAD(0x10f0) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_dat6.mmc1_dat6 */ + K2G_CORE_IOPAD(0x10f4) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_dat5.mmc1_dat5 */ + K2G_CORE_IOPAD(0x10f8) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_dat4.mmc1_dat4 */ + K2G_CORE_IOPAD(0x10fc) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_dat3.mmc1_dat3 */ + K2G_CORE_IOPAD(0x1100) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_dat2.mmc1_dat2 */ + K2G_CORE_IOPAD(0x1104) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_dat1.mmc1_dat1 */ + K2G_CORE_IOPAD(0x1108) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_dat0.mmc1_dat0 */ + K2G_CORE_IOPAD(0x110c) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_clk.mmc1_clk */ + K2G_CORE_IOPAD(0x1110) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_cmd.mmc1_cmd */ + >; + }; }; { @@ -41,3 +75,22 @@ pinctrl-0 = <_pins>; status = "okay"; }; + + { + status = "okay"; +}; + + { + pinctrl-names = "default"; + pinctrl-0 = <_pins>; + vmmc-supply = <_dcin_reg>; + cd-gpios = < 12 GPIO_ACTIVE_LOW>; + status = "okay"; +}; + + { + pinctrl-names = "default"; + pinctrl-0 = <_pins>; + vmmc-supply = <_dcin_reg>; /* VCC3V3_EMMC is connected to VCC3V3_DCIN */ + status = "okay"; +}; -- 2.13.0
[PATCH 0/6] ARM: dts: keystone-k2g: Add support for eDMA and MMC
This series adds DT nodes and documentation for eDMA and MMC IPs on Keystone 66AK2G SoC. Also enable the required configs in keystone_defconfig. This series depends on Keerthy's gpio node patches on 66AK2G: https://patchwork.kernel.org/patch/9864311/ Tested: k2g-evm with rootfs on mmc: http://pastebin.ubuntu.com/25217978/ Lokesh Vutla (5): dt-bindings: ti,edma: Add 66AK2G specific information dt-bindings: ti,omap-hsmmc: Add 66AK2G mmc controller ARM: dts: keystone-k2g: add MMC0 and MMC1 nodes ARM: dts: keystone-k2g-evm: Enable MMC0 and MMC1 ARM: configs: keystone: Enable MMC and regulators Peter Ujfalusi (1): ARM: dts: keystone-k2g: Add eDMA nodes Documentation/devicetree/bindings/dma/ti-edma.txt | 95 +++-- .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 52 arch/arm/boot/dts/keystone-k2g-evm.dts | 53 arch/arm/boot/dts/keystone-k2g.dtsi| 98 ++ arch/arm/configs/keystone_defconfig| 4 + 5 files changed, 282 insertions(+), 20 deletions(-) -- 2.13.0
[PATCH 5/6] ARM: dts: keystone-k2g-evm: Enable MMC0 and MMC1
Enable MMC0 which is used for micro SD and MMC1 which is used for the on board EMMC. Signed-off-by: Lokesh Vutla [fcoo...@ti.com: add mmc1, bufferclass and pullup/pulldown settings] Signed-off-by: Franklin S Cooper Jr [nsek...@ti.com: add card detect GPIO support] Signed-off-by: Sekhar Nori --- arch/arm/boot/dts/keystone-k2g-evm.dts | 53 ++ 1 file changed, 53 insertions(+) diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts b/arch/arm/boot/dts/keystone-k2g-evm.dts index 61883cb969d2..f47f95d8bf1c 100644 --- a/arch/arm/boot/dts/keystone-k2g-evm.dts +++ b/arch/arm/boot/dts/keystone-k2g-evm.dts @@ -25,6 +25,13 @@ reg = <0x0008 0x 0x 0x8000>; }; + vcc3v3_dcin_reg: fixedregulator-vcc3v3-dcin { + compatible = "regulator-fixed"; + regulator-name = "mmc0_fixed"; + regulator-min-microvolt = <330>; + regulator-max-microvolt = <330>; + regulator-always-on; + }; }; _pinctrl { @@ -34,6 +41,33 @@ K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN | MUX_MODE0) /* uart0_txd.uart0_txd */ >; }; + + mmc0_pins: pinmux_mmc0_pins { + pinctrl-single,pins = < + K2G_CORE_IOPAD(0x1300) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE2)/* mmc0_dat3.mmc0_dat3 */ + K2G_CORE_IOPAD(0x1304) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE2)/* mmc0_dat2.mmc0_dat2 */ + K2G_CORE_IOPAD(0x1308) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE2)/* mmc0_dat1.mmc0_dat1 */ + K2G_CORE_IOPAD(0x130c) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE2)/* mmc0_dat0.mmc0_dat0 */ + K2G_CORE_IOPAD(0x1310) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE2)/* mmc0_clk.mmc0_clk */ + K2G_CORE_IOPAD(0x1314) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE2)/* mmc0_cmd.mmc0_cmd */ + K2G_CORE_IOPAD(0x12ec) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE3)/* mmc0_sdcd.gpio1_12 */ + >; + }; + + mmc1_pins: pinmux_mmc1_pins { + pinctrl-single,pins = < + K2G_CORE_IOPAD(0x10ec) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_dat7.mmc1_dat7 */ + K2G_CORE_IOPAD(0x10f0) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_dat6.mmc1_dat6 */ + K2G_CORE_IOPAD(0x10f4) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_dat5.mmc1_dat5 */ + K2G_CORE_IOPAD(0x10f8) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_dat4.mmc1_dat4 */ + K2G_CORE_IOPAD(0x10fc) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_dat3.mmc1_dat3 */ + K2G_CORE_IOPAD(0x1100) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_dat2.mmc1_dat2 */ + K2G_CORE_IOPAD(0x1104) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_dat1.mmc1_dat1 */ + K2G_CORE_IOPAD(0x1108) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_dat0.mmc1_dat0 */ + K2G_CORE_IOPAD(0x110c) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_clk.mmc1_clk */ + K2G_CORE_IOPAD(0x1110) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)/* mmc1_cmd.mmc1_cmd */ + >; + }; }; { @@ -41,3 +75,22 @@ pinctrl-0 = <_pins>; status = "okay"; }; + + { + status = "okay"; +}; + + { + pinctrl-names = "default"; + pinctrl-0 = <_pins>; + vmmc-supply = <_dcin_reg>; + cd-gpios = < 12 GPIO_ACTIVE_LOW>; + status = "okay"; +}; + + { + pinctrl-names = "default"; + pinctrl-0 = <_pins>; + vmmc-supply = <_dcin_reg>; /* VCC3V3_EMMC is connected to VCC3V3_DCIN */ + status = "okay"; +}; -- 2.13.0
[PATCH 4/6] ARM: dts: keystone-k2g: add MMC0 and MMC1 nodes
Add device tree nodes for MMC0 and MMC1 pesent on 66AK2G device. Signed-off-by: Lokesh Vutla[nsek...@ti.com: fix clock-names for mmc1 node] Signed-off-by: Sekhar Nori --- arch/arm/boot/dts/keystone-k2g.dtsi | 32 1 file changed, 32 insertions(+) diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi index 3f1fd3df76d5..9ecea2c27d76 100644 --- a/arch/arm/boot/dts/keystone-k2g.dtsi +++ b/arch/arm/boot/dts/keystone-k2g.dtsi @@ -276,5 +276,37 @@ reg = <0x027b8000 0x400>; power-domains = <_pds 0x4f>; }; + + mmc0: mmc@2300 { + compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc"; + reg = <0x2300 0x400>; + interrupts = ; + dmas = < 24 0>, < 25 0>; + dma-names = "tx", "rx"; + bus-width = <4>; + ti,needs-special-reset; + no-1-8-v; + max-frequency = <9600>; + power-domains = <_pds 0xb>; + clocks = <_clks 0xb 1>, <_clks 0xb 2>; + clock-names = "fck", "mmchsdb_fck"; + status = "disabled"; + }; + + mmc1: mmc@2310 { + compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc"; + reg = <0x2310 0x400>; + interrupts = ; + dmas = < 26 0>, < 27 0>; + dma-names = "tx", "rx"; + bus-width = <8>; + ti,needs-special-reset; + ti,non-removable; + max-frequency = <9600>; + power-domains = <_pds 0xc>; + clocks = <_clks 0xc 1>, <_clks 0xc 2>; + clock-names = "fck", "mmchsdb_fck"; + status = "disabled"; + }; }; }; -- 2.13.0
[PATCH 4/6] ARM: dts: keystone-k2g: add MMC0 and MMC1 nodes
Add device tree nodes for MMC0 and MMC1 pesent on 66AK2G device. Signed-off-by: Lokesh Vutla [nsek...@ti.com: fix clock-names for mmc1 node] Signed-off-by: Sekhar Nori --- arch/arm/boot/dts/keystone-k2g.dtsi | 32 1 file changed, 32 insertions(+) diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi index 3f1fd3df76d5..9ecea2c27d76 100644 --- a/arch/arm/boot/dts/keystone-k2g.dtsi +++ b/arch/arm/boot/dts/keystone-k2g.dtsi @@ -276,5 +276,37 @@ reg = <0x027b8000 0x400>; power-domains = <_pds 0x4f>; }; + + mmc0: mmc@2300 { + compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc"; + reg = <0x2300 0x400>; + interrupts = ; + dmas = < 24 0>, < 25 0>; + dma-names = "tx", "rx"; + bus-width = <4>; + ti,needs-special-reset; + no-1-8-v; + max-frequency = <9600>; + power-domains = <_pds 0xb>; + clocks = <_clks 0xb 1>, <_clks 0xb 2>; + clock-names = "fck", "mmchsdb_fck"; + status = "disabled"; + }; + + mmc1: mmc@2310 { + compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc"; + reg = <0x2310 0x400>; + interrupts = ; + dmas = < 26 0>, < 27 0>; + dma-names = "tx", "rx"; + bus-width = <8>; + ti,needs-special-reset; + ti,non-removable; + max-frequency = <9600>; + power-domains = <_pds 0xc>; + clocks = <_clks 0xc 1>, <_clks 0xc 2>; + clock-names = "fck", "mmchsdb_fck"; + status = "disabled"; + }; }; }; -- 2.13.0
[PATCH 3/6] ARM: dts: keystone-k2g: Add eDMA nodes
From: Peter UjfalusiAdd nodes for eDMA0 and eDMA1. Signed-off-by: Peter Ujfalusi Signed-off-by: Dave Gerlach Signed-off-by: Lokesh Vutla --- arch/arm/boot/dts/keystone-k2g.dtsi | 66 + 1 file changed, 66 insertions(+) diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi index f9ff29972295..3f1fd3df76d5 100644 --- a/arch/arm/boot/dts/keystone-k2g.dtsi +++ b/arch/arm/boot/dts/keystone-k2g.dtsi @@ -210,5 +210,71 @@ clocks = <_clks 0x001c 0x0>; clock-names = "gpio"; }; + + edma0: edma@0270 { + compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc"; + reg = <0x0270 0x8000>; + reg-names = "edma3_cc"; + interrupts = , + , + ; + interrupt-names = "edma3_ccint", "emda3_mperr", + "edma3_ccerrint"; + dma-requests = <64>; + #dma-cells = <2>; + + ti,tptcs = <_tptc0 7>, <_tptc1 0>; + + ti,edma-memcpy-channels = <32 33 34 35>; + + power-domains = <_pds 0x3f>; + }; + + edma0_tptc0: tptc@0276 { + compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc"; + reg = <0x0276 0x400>; + power-domains = <_pds 0x3f>; + }; + + edma0_tptc1: tptc@02768000 { + compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc"; + reg = <0x02768000 0x400>; + power-domains = <_pds 0x3f>; + }; + + edma1: edma@02728000 { + compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc"; + reg = <0x02728000 0x8000>; + reg-names = "edma3_cc"; + interrupts = , + , + ; + interrupt-names = "edma3_ccint", "emda3_mperr", + "edma3_ccerrint"; + dma-requests = <64>; + #dma-cells = <2>; + + ti,tptcs = <_tptc0 7>, <_tptc1 0>; + + /* +* memcpy is disabled, can be enabled with: +* ti,edma-memcpy-channels = <12 13 14 15>; +* for example. +*/ + + power-domains = <_pds 0x4f>; + }; + + edma1_tptc0: tptc@027b { + compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc"; + reg = <0x027b 0x400>; + power-domains = <_pds 0x4f>; + }; + + edma1_tptc1: tptc@027b8000 { + compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc"; + reg = <0x027b8000 0x400>; + power-domains = <_pds 0x4f>; + }; }; }; -- 2.13.0
[PATCH 1/6] dt-bindings: ti,edma: Add 66AK2G specific information
Update ti,edma binding documentation to reflect 66AK2G specific properties. Signed-off-by: Lokesh Vutla--- Documentation/devicetree/bindings/dma/ti-edma.txt | 95 +-- 1 file changed, 90 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt index 18090e7226b4..05fe2931d025 100644 --- a/Documentation/devicetree/bindings/dma/ti-edma.txt +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt @@ -9,7 +9,12 @@ execute the actual DMA tansfer. eDMA3 Channel Controller Required properties: -- compatible: "ti,edma3-tpcc" for the channel controller(s) + +- compatible: Should be: + - "ti,edma3-tpcc" for the channel controller(s) on OMAP, + AM33xx and AM43xx SoCs. + - "ti,k2g-edma3-tpcc", "ti,edma3-tpcc" for the + channel controller(s) on 66AK2G. - #dma-cells: Should be set to <2>. The first number is the DMA request number and the second is the TC the channel is serviced on. - reg: Memory map of eDMA CC @@ -19,8 +24,19 @@ Required properties: - ti,tptcs:List of TPTCs associated with the eDMA in the following form: <_phandle TC_priority_number>. The highest priority is 0. +SoC-specific Required properties: + +The following are mandatory properties for OMAP, AM33xx and AM43xx SoCs only: +- ti,hwmods: Name of the hwmods associated to the eDMA CC. + +The following are mandatory properties for 66AK2G SoCs only: +- power-domains:Should contain a phandle to a PM domain provider node + and an args specifier containing the device id + value. This property is as per the binding, + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Optional properties: -- ti,hwmods: Name of the hwmods associated to the eDMA CC +--- - ti,edma-memcpy-channels: List of channels allocated to be used for memcpy, iow these channels will be SW triggered channels. See example. - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by @@ -31,17 +47,34 @@ Optional properties: eDMA3 Transfer Controller Required properties: -- compatible: "ti,edma3-tptc" for the transfer controller(s) + +- compatible: Should be: + - "ti,edma3-tptc" for the transfer controller(s) on OMAP, + AM33xx and AM43xx SoCs. + - "ti,k2g-edma3-tptc", "ti,edma3-tptc" for the + transfer controller(s) on 66AK2G. - reg: Memory map of eDMA TC - interrupts: Interrupt number for TCerrint. +SoC-specific Required properties: + +The following are mandatory properties for OMAP, AM33xx and AM43xx SoCs only: +- ti,hwmods: Name of the hwmods associated to the eDMA TC. + +The following are mandatory properties for 66AK2G SoCs only: +- power-domains:Should contain a phandle to a PM domain provider node + and an args specifier containing the device id + value. This property is as per the binding, + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Optional properties: -- ti,hwmods: Name of the hwmods associated to the given eDMA TC +--- - interrupt-names: "edma3_tcerrint" -- -Example: +Examples: +1. edma: edma@4900 { compatible = "ti,edma3-tpcc"; ti,hwmods = "tpcc"; @@ -109,6 +142,58 @@ mcasp0: mcasp@48038000 { dma-names = "tx", "rx"; }; +2. +edma1: edma@02728000 { + compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc"; + reg = <0x02728000 0x8000>; + reg-names = "edma3_cc"; + interrupts = , + , + ; + interrupt-names = "edma3_ccint", "emda3_mperr", + "edma3_ccerrint"; + dma-requests = <64>; + #dma-cells = <2>; + + ti,tptcs = <_tptc0 7>, <_tptc1 0>; + + /* +* memcpy is disabled, can be enabled with: +* ti,edma-memcpy-channels = <12 13 14 15>; +* for example. +*/ + + power-domains = <_pds 0x4f>; +}; + +edma1_tptc0: tptc@027b { + compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc"; + reg = <0x027b 0x400>; + power-domains = <_pds 0x4f>; +}; + +edma1_tptc1: tptc@027b8000 { + compatible = "ti, k2g-edma3-tptc", "ti,edma3-tptc"; + reg = <0x027b8000 0x400>; + power-domains = <_pds 0x4f>; +}; + +mmc0: mmc@2300 { + compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc"; + reg = <0x2300 0x400>; + interrupts = ; + dmas = < 24 0>, < 25 0>; + dma-names = "tx", "rx"; + bus-width = <4>; + ti,needs-special-reset; + no-1-8-v; + max-frequency =
[PATCH 3/6] ARM: dts: keystone-k2g: Add eDMA nodes
From: Peter Ujfalusi Add nodes for eDMA0 and eDMA1. Signed-off-by: Peter Ujfalusi Signed-off-by: Dave Gerlach Signed-off-by: Lokesh Vutla --- arch/arm/boot/dts/keystone-k2g.dtsi | 66 + 1 file changed, 66 insertions(+) diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi index f9ff29972295..3f1fd3df76d5 100644 --- a/arch/arm/boot/dts/keystone-k2g.dtsi +++ b/arch/arm/boot/dts/keystone-k2g.dtsi @@ -210,5 +210,71 @@ clocks = <_clks 0x001c 0x0>; clock-names = "gpio"; }; + + edma0: edma@0270 { + compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc"; + reg = <0x0270 0x8000>; + reg-names = "edma3_cc"; + interrupts = , + , + ; + interrupt-names = "edma3_ccint", "emda3_mperr", + "edma3_ccerrint"; + dma-requests = <64>; + #dma-cells = <2>; + + ti,tptcs = <_tptc0 7>, <_tptc1 0>; + + ti,edma-memcpy-channels = <32 33 34 35>; + + power-domains = <_pds 0x3f>; + }; + + edma0_tptc0: tptc@0276 { + compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc"; + reg = <0x0276 0x400>; + power-domains = <_pds 0x3f>; + }; + + edma0_tptc1: tptc@02768000 { + compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc"; + reg = <0x02768000 0x400>; + power-domains = <_pds 0x3f>; + }; + + edma1: edma@02728000 { + compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc"; + reg = <0x02728000 0x8000>; + reg-names = "edma3_cc"; + interrupts = , + , + ; + interrupt-names = "edma3_ccint", "emda3_mperr", + "edma3_ccerrint"; + dma-requests = <64>; + #dma-cells = <2>; + + ti,tptcs = <_tptc0 7>, <_tptc1 0>; + + /* +* memcpy is disabled, can be enabled with: +* ti,edma-memcpy-channels = <12 13 14 15>; +* for example. +*/ + + power-domains = <_pds 0x4f>; + }; + + edma1_tptc0: tptc@027b { + compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc"; + reg = <0x027b 0x400>; + power-domains = <_pds 0x4f>; + }; + + edma1_tptc1: tptc@027b8000 { + compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc"; + reg = <0x027b8000 0x400>; + power-domains = <_pds 0x4f>; + }; }; }; -- 2.13.0
[PATCH 1/6] dt-bindings: ti,edma: Add 66AK2G specific information
Update ti,edma binding documentation to reflect 66AK2G specific properties. Signed-off-by: Lokesh Vutla --- Documentation/devicetree/bindings/dma/ti-edma.txt | 95 +-- 1 file changed, 90 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt index 18090e7226b4..05fe2931d025 100644 --- a/Documentation/devicetree/bindings/dma/ti-edma.txt +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt @@ -9,7 +9,12 @@ execute the actual DMA tansfer. eDMA3 Channel Controller Required properties: -- compatible: "ti,edma3-tpcc" for the channel controller(s) + +- compatible: Should be: + - "ti,edma3-tpcc" for the channel controller(s) on OMAP, + AM33xx and AM43xx SoCs. + - "ti,k2g-edma3-tpcc", "ti,edma3-tpcc" for the + channel controller(s) on 66AK2G. - #dma-cells: Should be set to <2>. The first number is the DMA request number and the second is the TC the channel is serviced on. - reg: Memory map of eDMA CC @@ -19,8 +24,19 @@ Required properties: - ti,tptcs:List of TPTCs associated with the eDMA in the following form: <_phandle TC_priority_number>. The highest priority is 0. +SoC-specific Required properties: + +The following are mandatory properties for OMAP, AM33xx and AM43xx SoCs only: +- ti,hwmods: Name of the hwmods associated to the eDMA CC. + +The following are mandatory properties for 66AK2G SoCs only: +- power-domains:Should contain a phandle to a PM domain provider node + and an args specifier containing the device id + value. This property is as per the binding, + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Optional properties: -- ti,hwmods: Name of the hwmods associated to the eDMA CC +--- - ti,edma-memcpy-channels: List of channels allocated to be used for memcpy, iow these channels will be SW triggered channels. See example. - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by @@ -31,17 +47,34 @@ Optional properties: eDMA3 Transfer Controller Required properties: -- compatible: "ti,edma3-tptc" for the transfer controller(s) + +- compatible: Should be: + - "ti,edma3-tptc" for the transfer controller(s) on OMAP, + AM33xx and AM43xx SoCs. + - "ti,k2g-edma3-tptc", "ti,edma3-tptc" for the + transfer controller(s) on 66AK2G. - reg: Memory map of eDMA TC - interrupts: Interrupt number for TCerrint. +SoC-specific Required properties: + +The following are mandatory properties for OMAP, AM33xx and AM43xx SoCs only: +- ti,hwmods: Name of the hwmods associated to the eDMA TC. + +The following are mandatory properties for 66AK2G SoCs only: +- power-domains:Should contain a phandle to a PM domain provider node + and an args specifier containing the device id + value. This property is as per the binding, + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Optional properties: -- ti,hwmods: Name of the hwmods associated to the given eDMA TC +--- - interrupt-names: "edma3_tcerrint" -- -Example: +Examples: +1. edma: edma@4900 { compatible = "ti,edma3-tpcc"; ti,hwmods = "tpcc"; @@ -109,6 +142,58 @@ mcasp0: mcasp@48038000 { dma-names = "tx", "rx"; }; +2. +edma1: edma@02728000 { + compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc"; + reg = <0x02728000 0x8000>; + reg-names = "edma3_cc"; + interrupts = , + , + ; + interrupt-names = "edma3_ccint", "emda3_mperr", + "edma3_ccerrint"; + dma-requests = <64>; + #dma-cells = <2>; + + ti,tptcs = <_tptc0 7>, <_tptc1 0>; + + /* +* memcpy is disabled, can be enabled with: +* ti,edma-memcpy-channels = <12 13 14 15>; +* for example. +*/ + + power-domains = <_pds 0x4f>; +}; + +edma1_tptc0: tptc@027b { + compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc"; + reg = <0x027b 0x400>; + power-domains = <_pds 0x4f>; +}; + +edma1_tptc1: tptc@027b8000 { + compatible = "ti, k2g-edma3-tptc", "ti,edma3-tptc"; + reg = <0x027b8000 0x400>; + power-domains = <_pds 0x4f>; +}; + +mmc0: mmc@2300 { + compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc"; + reg = <0x2300 0x400>; + interrupts = ; + dmas = < 24 0>, < 25 0>; + dma-names = "tx", "rx"; + bus-width = <4>; + ti,needs-special-reset; + no-1-8-v; + max-frequency = <9600>; +
[PATCH v2] Coccinelle: Script to remove unnecessary static on local variables
Coccinelle script to remove unnecessary static on local variables when the variables are not used before update. Signed-off-by: Gustavo A. R. Silva--- Changes in v2: Update header and Copyright note. scripts/coccinelle/misc/static_unnecessary.cocci | 96 1 file changed, 96 insertions(+) create mode 100644 scripts/coccinelle/misc/static_unnecessary.cocci diff --git a/scripts/coccinelle/misc/static_unnecessary.cocci b/scripts/coccinelle/misc/static_unnecessary.cocci new file mode 100644 index 000..2b10586 --- /dev/null +++ b/scripts/coccinelle/misc/static_unnecessary.cocci @@ -0,0 +1,96 @@ +/// Drop static on local variable when the variable is not used before update. +//# +//# Removing unnecessary static on local variables reduces the code +//# size and increases maintainability. +//# +//# On the other hand, even though it is rare, be aware that if a +//# large object is initialized all at once, it might not be wise +//# to remove the static because that would increase the risk of a +//# stack overflow. +/// +// Confidence: Moderate +// Copyright: (C) 2017 Julia Lawall, Inria. GPLv2. +// URL: http://coccinelle.lip6.fr/ +// Copyright: (C) 2017 Gustavo A. R. Silva. GPLv2. +// Work supported by a grant from +// The Linux Foundation's Core Infrastructure Initiative. +// URL: https://www.coreinfrastructure.org/ +// Options: --no-includes --include-headers +// Keywords: static + +virtual patch +virtual context +virtual org +virtual report + +// +@bad exists@ +position p; +identifier x; +expression e; +type T; +@@ + +T x@p; +... when != x = e +x = <+...x...+> + +@worse exists@ +position p; +identifier x; +type T; +@@ + +T x@p; +... + + +@modify depends on patch && !context && !org && !report@ +identifier x; +expression e; +type T; +position p != {bad.p,worse.p}; +@@ + +-static + T x@p; + ... when != x + when strict +?x = e; +// + + +// + +@modify_context depends on !patch && (context || org || report) forall@ +type T; +identifier x; +expression e; +position p != {bad.p,worse.p}; +position j0; +@@ + +* static + T x@j0@p; + ... when != x + when strict +?x = e; + +// + +@script:python modify_org depends on org@ +j0 << modify_context.j0; +@@ + +msg = "Unnecessary static on local variable." +coccilib.org.print_todo(j0[0], msg) + +// + +@script:python modify_report depends on report@ +j0 << modify_context.j0; +@@ + +msg = "Unnecessary static on local variable." +coccilib.report.print_report(j0[0], msg) + -- 2.5.0
[PATCH v2] Coccinelle: Script to remove unnecessary static on local variables
Coccinelle script to remove unnecessary static on local variables when the variables are not used before update. Signed-off-by: Gustavo A. R. Silva --- Changes in v2: Update header and Copyright note. scripts/coccinelle/misc/static_unnecessary.cocci | 96 1 file changed, 96 insertions(+) create mode 100644 scripts/coccinelle/misc/static_unnecessary.cocci diff --git a/scripts/coccinelle/misc/static_unnecessary.cocci b/scripts/coccinelle/misc/static_unnecessary.cocci new file mode 100644 index 000..2b10586 --- /dev/null +++ b/scripts/coccinelle/misc/static_unnecessary.cocci @@ -0,0 +1,96 @@ +/// Drop static on local variable when the variable is not used before update. +//# +//# Removing unnecessary static on local variables reduces the code +//# size and increases maintainability. +//# +//# On the other hand, even though it is rare, be aware that if a +//# large object is initialized all at once, it might not be wise +//# to remove the static because that would increase the risk of a +//# stack overflow. +/// +// Confidence: Moderate +// Copyright: (C) 2017 Julia Lawall, Inria. GPLv2. +// URL: http://coccinelle.lip6.fr/ +// Copyright: (C) 2017 Gustavo A. R. Silva. GPLv2. +// Work supported by a grant from +// The Linux Foundation's Core Infrastructure Initiative. +// URL: https://www.coreinfrastructure.org/ +// Options: --no-includes --include-headers +// Keywords: static + +virtual patch +virtual context +virtual org +virtual report + +// +@bad exists@ +position p; +identifier x; +expression e; +type T; +@@ + +T x@p; +... when != x = e +x = <+...x...+> + +@worse exists@ +position p; +identifier x; +type T; +@@ + +T x@p; +... + + +@modify depends on patch && !context && !org && !report@ +identifier x; +expression e; +type T; +position p != {bad.p,worse.p}; +@@ + +-static + T x@p; + ... when != x + when strict +?x = e; +// + + +// + +@modify_context depends on !patch && (context || org || report) forall@ +type T; +identifier x; +expression e; +position p != {bad.p,worse.p}; +position j0; +@@ + +* static + T x@j0@p; + ... when != x + when strict +?x = e; + +// + +@script:python modify_org depends on org@ +j0 << modify_context.j0; +@@ + +msg = "Unnecessary static on local variable." +coccilib.org.print_todo(j0[0], msg) + +// + +@script:python modify_report depends on report@ +j0 << modify_context.j0; +@@ + +msg = "Unnecessary static on local variable." +coccilib.report.print_report(j0[0], msg) + -- 2.5.0
Re: [PATCH] staging: ks7010: fix styling WARNINGs
Hi Ashish, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.13-rc3 next-20170731] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ashish-Kalra/staging-ks7010-fix-styling-WARNINGs/20170801-121331 config: tile-allmodconfig (attached as .config) compiler: tilegx-linux-gcc (GCC) 4.6.2 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=tile All errors (new ones prefixed by >>): drivers/staging//ks7010/ks7010_sdio.c: In function 'ks7010_sdio_readb': drivers/staging//ks7010/ks7010_sdio.c:77:12: error: invalid storage class for function 'ks7010_sdio_readb' drivers/staging//ks7010/ks7010_sdio.c:77:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] drivers/staging//ks7010/ks7010_sdio.c:89:12: error: invalid storage class for function 'ks7010_sdio_read' drivers/staging//ks7010/ks7010_sdio.c:98:12: error: invalid storage class for function 'ks7010_sdio_writeb' drivers/staging//ks7010/ks7010_sdio.c:110:12: error: invalid storage class for function 'ks7010_sdio_write' drivers/staging//ks7010/ks7010_sdio.c:118:13: error: invalid storage class for function 'ks_wlan_hw_sleep_doze_request' drivers/staging//ks7010/ks7010_sdio.c:144:13: error: invalid storage class for function 'ks_wlan_hw_sleep_wakeup_request' drivers/staging//ks7010/ks7010_sdio.c:191:13: error: invalid storage class for function '_ks_wlan_hw_power_save' drivers/staging//ks7010/ks7010_sdio.c:252:12: error: invalid storage class for function 'enqueue_txdev' drivers/staging//ks7010/ks7010_sdio.c:290:12: error: invalid storage class for function 'write_to_device' drivers/staging//ks7010/ks7010_sdio.c:320:13: error: invalid storage class for function 'tx_device_task' drivers/staging//ks7010/ks7010_sdio.c:379:13: error: invalid storage class for function 'rx_event_task' drivers/staging//ks7010/ks7010_sdio.c:396:13: error: invalid storage class for function 'ks_wlan_hw_rx' drivers/staging//ks7010/ks7010_sdio.c:452:13: error: invalid storage class for function 'ks7010_rw_function' drivers/staging//ks7010/ks7010_sdio.c:522:13: error: invalid storage class for function 'ks_sdio_interrupt' drivers/staging//ks7010/ks7010_sdio.c:593:12: error: invalid storage class for function 'trx_device_init' drivers/staging//ks7010/ks7010_sdio.c:609:13: error: invalid storage class for function 'trx_device_exit' drivers/staging//ks7010/ks7010_sdio.c:625:12: error: invalid storage class for function 'ks7010_sdio_update_index' drivers/staging//ks7010/ks7010_sdio.c:652:12: error: invalid storage class for function 'ks7010_sdio_data_compare' drivers/staging//ks7010/ks7010_sdio.c:680:12: error: invalid storage class for function 'ks7010_upload_firmware' drivers/staging//ks7010/ks7010_sdio.c:775:13: error: invalid storage class for function 'ks7010_card_init' drivers/staging//ks7010/ks7010_sdio.c:828:13: error: invalid storage class for function 'ks7010_init_defaults' drivers/staging//ks7010/ks7010_sdio.c:855:12: error: invalid storage class for function 'ks7010_sdio_probe' drivers/staging//ks7010/ks7010_sdio.c:1005:12: error: invalid storage class for function 'send_stop_request' drivers/staging//ks7010/ks7010_sdio.c:1032:13: error: invalid storage class for function 'ks7010_sdio_remove' drivers/staging//ks7010/ks7010_sdio.c:1100:2: error: initializer element is not constant drivers/staging//ks7010/ks7010_sdio.c:1100:2: error: (near initialization for 'ks7010_sdio_driver.probe') drivers/staging//ks7010/ks7010_sdio.c:1101:2: error: initializer element is not constant drivers/staging//ks7010/ks7010_sdio.c:1101:2: error: (near initialization for 'ks7010_sdio_driver.remove') drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class for function 'ks7010_sdio_driver_init' >> drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class >> for function '__inittest' drivers/staging//ks7010/ks7010_sdio.c:1104:1: warning: 'alias' attribute ignored [-Wattributes] drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class for function 'ks7010_sdio_driver_exit' drivers/staging//ks7010/ks7010_sdio.c:1104:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] >> drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class >> for function '__exittest' drivers/staging//ks7010/ks7010_sdio.c:1104:1: warning: 'alias' attribute ignored [-Wattributes] drivers/staging//ks7010/ks7010_sdio.c:1105:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] drivers/stag
Re: [PATCH] staging: ks7010: fix styling WARNINGs
Hi Ashish, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.13-rc3 next-20170731] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ashish-Kalra/staging-ks7010-fix-styling-WARNINGs/20170801-121331 config: tile-allmodconfig (attached as .config) compiler: tilegx-linux-gcc (GCC) 4.6.2 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=tile All errors (new ones prefixed by >>): drivers/staging//ks7010/ks7010_sdio.c: In function 'ks7010_sdio_readb': drivers/staging//ks7010/ks7010_sdio.c:77:12: error: invalid storage class for function 'ks7010_sdio_readb' drivers/staging//ks7010/ks7010_sdio.c:77:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] drivers/staging//ks7010/ks7010_sdio.c:89:12: error: invalid storage class for function 'ks7010_sdio_read' drivers/staging//ks7010/ks7010_sdio.c:98:12: error: invalid storage class for function 'ks7010_sdio_writeb' drivers/staging//ks7010/ks7010_sdio.c:110:12: error: invalid storage class for function 'ks7010_sdio_write' drivers/staging//ks7010/ks7010_sdio.c:118:13: error: invalid storage class for function 'ks_wlan_hw_sleep_doze_request' drivers/staging//ks7010/ks7010_sdio.c:144:13: error: invalid storage class for function 'ks_wlan_hw_sleep_wakeup_request' drivers/staging//ks7010/ks7010_sdio.c:191:13: error: invalid storage class for function '_ks_wlan_hw_power_save' drivers/staging//ks7010/ks7010_sdio.c:252:12: error: invalid storage class for function 'enqueue_txdev' drivers/staging//ks7010/ks7010_sdio.c:290:12: error: invalid storage class for function 'write_to_device' drivers/staging//ks7010/ks7010_sdio.c:320:13: error: invalid storage class for function 'tx_device_task' drivers/staging//ks7010/ks7010_sdio.c:379:13: error: invalid storage class for function 'rx_event_task' drivers/staging//ks7010/ks7010_sdio.c:396:13: error: invalid storage class for function 'ks_wlan_hw_rx' drivers/staging//ks7010/ks7010_sdio.c:452:13: error: invalid storage class for function 'ks7010_rw_function' drivers/staging//ks7010/ks7010_sdio.c:522:13: error: invalid storage class for function 'ks_sdio_interrupt' drivers/staging//ks7010/ks7010_sdio.c:593:12: error: invalid storage class for function 'trx_device_init' drivers/staging//ks7010/ks7010_sdio.c:609:13: error: invalid storage class for function 'trx_device_exit' drivers/staging//ks7010/ks7010_sdio.c:625:12: error: invalid storage class for function 'ks7010_sdio_update_index' drivers/staging//ks7010/ks7010_sdio.c:652:12: error: invalid storage class for function 'ks7010_sdio_data_compare' drivers/staging//ks7010/ks7010_sdio.c:680:12: error: invalid storage class for function 'ks7010_upload_firmware' drivers/staging//ks7010/ks7010_sdio.c:775:13: error: invalid storage class for function 'ks7010_card_init' drivers/staging//ks7010/ks7010_sdio.c:828:13: error: invalid storage class for function 'ks7010_init_defaults' drivers/staging//ks7010/ks7010_sdio.c:855:12: error: invalid storage class for function 'ks7010_sdio_probe' drivers/staging//ks7010/ks7010_sdio.c:1005:12: error: invalid storage class for function 'send_stop_request' drivers/staging//ks7010/ks7010_sdio.c:1032:13: error: invalid storage class for function 'ks7010_sdio_remove' drivers/staging//ks7010/ks7010_sdio.c:1100:2: error: initializer element is not constant drivers/staging//ks7010/ks7010_sdio.c:1100:2: error: (near initialization for 'ks7010_sdio_driver.probe') drivers/staging//ks7010/ks7010_sdio.c:1101:2: error: initializer element is not constant drivers/staging//ks7010/ks7010_sdio.c:1101:2: error: (near initialization for 'ks7010_sdio_driver.remove') drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class for function 'ks7010_sdio_driver_init' >> drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class >> for function '__inittest' drivers/staging//ks7010/ks7010_sdio.c:1104:1: warning: 'alias' attribute ignored [-Wattributes] drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class for function 'ks7010_sdio_driver_exit' drivers/staging//ks7010/ks7010_sdio.c:1104:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] >> drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class >> for function '__exittest' drivers/staging//ks7010/ks7010_sdio.c:1104:1: warning: 'alias' attribute ignored [-Wattributes] drivers/staging//ks7010/ks7010_sdio.c:1105:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] drivers/stag
RE: [PATCH v2] ASoC: Intel: Reset hw_ptr on resume trigger
This patch was originally submitted in the context of the ChromiumOS kernel 3.10 for BYT (https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/AsoBhfHzQg8). > -Original Message- > From: Koul, Vinod > Sent: Monday, July 31, 2017 8:30 PM > To: Cheng-Yi Chiang; Jie, Yang > Cc: linux-kernel@vger.kernel.org; Liam Girdwood ; Mark > Brown ; Jaroslav Kysela > ; Takashi Iwai ; Eoff, Ullysses A > ; alsa-de...@alsa-project.org > Subject: Re: [PATCH v2] ASoC: Intel: Reset hw_ptr on resume trigger > > On Mon, Jul 31, 2017 at 06:47:34PM +0800, Cheng-Yi Chiang wrote: > > From: "U. Artie Eoff" > > > > Reset the hw_ptr before queuing the restore_stream_context > > work to eradicate a nasty white audio noise on resume. > > Liam, Jie? This on legacy BYT driver.. > > > > > Tested-by: Cheng-Yi Chiang > > Signed-off-by: U. Artie Eoff > > Signed-off-by: Cheng-Yi Chiang > > --- > > sound/soc/intel/baytrail/sst-baytrail-pcm.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/sound/soc/intel/baytrail/sst-baytrail-pcm.c > > b/sound/soc/intel/baytrail/sst-baytrail-pcm.c > > index 4765ad474544..e0db7070cd42 100644 > > --- a/sound/soc/intel/baytrail/sst-baytrail-pcm.c > > +++ b/sound/soc/intel/baytrail/sst-baytrail-pcm.c > > @@ -187,8 +187,10 @@ static int sst_byt_pcm_trigger(struct > > snd_pcm_substream *substream, int cmd) > > sst_byt_stream_start(byt, pcm_data->stream, 0); > > break; > > case SNDRV_PCM_TRIGGER_RESUME: > > - if (pdata->restore_stream == true) > > + if (pdata->restore_stream == true) { > > + pcm_data->hw_ptr = 0; > > schedule_work(_data->work); > > + } > > else > > sst_byt_stream_resume(byt, pcm_data->stream); > > break; > > -- > > 2.12.2 > > > > -- > ~Vinod
RE: [PATCH v2] ASoC: Intel: Reset hw_ptr on resume trigger
This patch was originally submitted in the context of the ChromiumOS kernel 3.10 for BYT (https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/AsoBhfHzQg8). > -Original Message- > From: Koul, Vinod > Sent: Monday, July 31, 2017 8:30 PM > To: Cheng-Yi Chiang ; Jie, Yang > Cc: linux-kernel@vger.kernel.org; Liam Girdwood ; Mark > Brown ; Jaroslav Kysela > ; Takashi Iwai ; Eoff, Ullysses A > ; alsa-de...@alsa-project.org > Subject: Re: [PATCH v2] ASoC: Intel: Reset hw_ptr on resume trigger > > On Mon, Jul 31, 2017 at 06:47:34PM +0800, Cheng-Yi Chiang wrote: > > From: "U. Artie Eoff" > > > > Reset the hw_ptr before queuing the restore_stream_context > > work to eradicate a nasty white audio noise on resume. > > Liam, Jie? This on legacy BYT driver.. > > > > > Tested-by: Cheng-Yi Chiang > > Signed-off-by: U. Artie Eoff > > Signed-off-by: Cheng-Yi Chiang > > --- > > sound/soc/intel/baytrail/sst-baytrail-pcm.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/sound/soc/intel/baytrail/sst-baytrail-pcm.c > > b/sound/soc/intel/baytrail/sst-baytrail-pcm.c > > index 4765ad474544..e0db7070cd42 100644 > > --- a/sound/soc/intel/baytrail/sst-baytrail-pcm.c > > +++ b/sound/soc/intel/baytrail/sst-baytrail-pcm.c > > @@ -187,8 +187,10 @@ static int sst_byt_pcm_trigger(struct > > snd_pcm_substream *substream, int cmd) > > sst_byt_stream_start(byt, pcm_data->stream, 0); > > break; > > case SNDRV_PCM_TRIGGER_RESUME: > > - if (pdata->restore_stream == true) > > + if (pdata->restore_stream == true) { > > + pcm_data->hw_ptr = 0; > > schedule_work(_data->work); > > + } > > else > > sst_byt_stream_resume(byt, pcm_data->stream); > > break; > > -- > > 2.12.2 > > > > -- > ~Vinod
Re: [PATCH] staging: ks7010: fix styling WARNINGs
Hi Ashish, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.13-rc3 next-20170731] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ashish-Kalra/staging-ks7010-fix-styling-WARNINGs/20170801-121331 config: i386-randconfig-x008-201731 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386 All error/warnings (new ones prefixed by >>): drivers/staging/ks7010/ks7010_sdio.c: In function 'ks7010_sdio_readb': >> drivers/staging/ks7010/ks7010_sdio.c:77:12: error: invalid storage class for >> function 'ks7010_sdio_readb' static int ks7010_sdio_readb(struct ks_wlan_private *priv, unsigned int address, ^ >> drivers/staging/ks7010/ks7010_sdio.c:77:1: warning: ISO C90 forbids mixed >> declarations and code [-Wdeclaration-after-statement] static int ks7010_sdio_readb(struct ks_wlan_private *priv, unsigned int address, ^~ >> drivers/staging/ks7010/ks7010_sdio.c:89:12: error: invalid storage class for >> function 'ks7010_sdio_read' static int ks7010_sdio_read(struct ks_wlan_private *priv, unsigned int address, ^~~~ >> drivers/staging/ks7010/ks7010_sdio.c:98:12: error: invalid storage class for >> function 'ks7010_sdio_writeb' static int ks7010_sdio_writeb(struct ks_wlan_private *priv, ^~ >> drivers/staging/ks7010/ks7010_sdio.c:110:12: error: invalid storage class >> for function 'ks7010_sdio_write' static int ks7010_sdio_write(struct ks_wlan_private *priv, unsigned int address, ^ >> drivers/staging/ks7010/ks7010_sdio.c:118:13: error: invalid storage class >> for function 'ks_wlan_hw_sleep_doze_request' static void ks_wlan_hw_sleep_doze_request(struct ks_wlan_private *priv) ^ >> drivers/staging/ks7010/ks7010_sdio.c:144:13: error: invalid storage class >> for function 'ks_wlan_hw_sleep_wakeup_request' static void ks_wlan_hw_sleep_wakeup_request(struct ks_wlan_private *priv) ^~~ >> drivers/staging/ks7010/ks7010_sdio.c:191:13: error: invalid storage class >> for function '_ks_wlan_hw_power_save' static void _ks_wlan_hw_power_save(struct ks_wlan_private *priv) ^~ >> drivers/staging/ks7010/ks7010_sdio.c:252:12: error: invalid storage class >> for function 'enqueue_txdev' static int enqueue_txdev(struct ks_wlan_private *priv, unsigned char *p, ^ >> drivers/staging/ks7010/ks7010_sdio.c:290:12: error: invalid storage class >> for function 'write_to_device' static int write_to_device(struct ks_wlan_private *priv, unsigned char *buffer, ^~~ >> drivers/staging/ks7010/ks7010_sdio.c:320:13: error: invalid storage class >> for function 'tx_device_task' static void tx_device_task(struct ks_wlan_private *priv) ^~ >> drivers/staging/ks7010/ks7010_sdio.c:379:13: error: invalid storage class >> for function 'rx_event_task' static void rx_event_task(unsigned long dev) ^ >> drivers/staging/ks7010/ks7010_sdio.c:396:13: error: invalid storage class >> for function 'ks_wlan_hw_rx' static void ks_wlan_hw_rx(struct ks_wlan_private *priv, uint16_t size) ^ >> drivers/staging/ks7010/ks7010_sdio.c:452:13: error: invalid storage class >> for function 'ks7010_rw_function' static void ks7010_rw_function(struct work_struct *work) ^~ >> drivers/staging/ks7010/ks7010_sdio.c:522:13: error: invalid storage class >> for function 'ks_sdio_interrupt' static void ks_sdio_interrupt(struct sdio_func *func) ^ >> drivers/staging/ks7010/ks7010_sdio.c:593:12: error: invalid storage class >> for function 'trx_device_init' static int trx_device_init(struct ks_wlan_private *priv) ^~~ >> drivers/staging/ks7010/ks7010_sdio.c:609:13: error: invalid storage class >> for function 'trx_device_exit' static void trx_device_exit(struct ks_wlan_private *priv) ^~~ >> drivers/staging/ks7010/ks7010_sdio.c:625:12: error: invalid storage class >> for function 'ks7010_sdio_update_index' static int ks7010_sdio_update_index(struct ks_wlan_private *priv, u32 index) ^~~~ >> drivers/staging/ks7010/ks7010_sdio.c:652:12: error: invalid storage class >> for function 'ks7010_sdio_data_compare' sta
Re: [PATCH] staging: ks7010: fix styling WARNINGs
Hi Ashish, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.13-rc3 next-20170731] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ashish-Kalra/staging-ks7010-fix-styling-WARNINGs/20170801-121331 config: i386-randconfig-x008-201731 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386 All error/warnings (new ones prefixed by >>): drivers/staging/ks7010/ks7010_sdio.c: In function 'ks7010_sdio_readb': >> drivers/staging/ks7010/ks7010_sdio.c:77:12: error: invalid storage class for >> function 'ks7010_sdio_readb' static int ks7010_sdio_readb(struct ks_wlan_private *priv, unsigned int address, ^ >> drivers/staging/ks7010/ks7010_sdio.c:77:1: warning: ISO C90 forbids mixed >> declarations and code [-Wdeclaration-after-statement] static int ks7010_sdio_readb(struct ks_wlan_private *priv, unsigned int address, ^~ >> drivers/staging/ks7010/ks7010_sdio.c:89:12: error: invalid storage class for >> function 'ks7010_sdio_read' static int ks7010_sdio_read(struct ks_wlan_private *priv, unsigned int address, ^~~~ >> drivers/staging/ks7010/ks7010_sdio.c:98:12: error: invalid storage class for >> function 'ks7010_sdio_writeb' static int ks7010_sdio_writeb(struct ks_wlan_private *priv, ^~ >> drivers/staging/ks7010/ks7010_sdio.c:110:12: error: invalid storage class >> for function 'ks7010_sdio_write' static int ks7010_sdio_write(struct ks_wlan_private *priv, unsigned int address, ^ >> drivers/staging/ks7010/ks7010_sdio.c:118:13: error: invalid storage class >> for function 'ks_wlan_hw_sleep_doze_request' static void ks_wlan_hw_sleep_doze_request(struct ks_wlan_private *priv) ^ >> drivers/staging/ks7010/ks7010_sdio.c:144:13: error: invalid storage class >> for function 'ks_wlan_hw_sleep_wakeup_request' static void ks_wlan_hw_sleep_wakeup_request(struct ks_wlan_private *priv) ^~~ >> drivers/staging/ks7010/ks7010_sdio.c:191:13: error: invalid storage class >> for function '_ks_wlan_hw_power_save' static void _ks_wlan_hw_power_save(struct ks_wlan_private *priv) ^~ >> drivers/staging/ks7010/ks7010_sdio.c:252:12: error: invalid storage class >> for function 'enqueue_txdev' static int enqueue_txdev(struct ks_wlan_private *priv, unsigned char *p, ^ >> drivers/staging/ks7010/ks7010_sdio.c:290:12: error: invalid storage class >> for function 'write_to_device' static int write_to_device(struct ks_wlan_private *priv, unsigned char *buffer, ^~~ >> drivers/staging/ks7010/ks7010_sdio.c:320:13: error: invalid storage class >> for function 'tx_device_task' static void tx_device_task(struct ks_wlan_private *priv) ^~ >> drivers/staging/ks7010/ks7010_sdio.c:379:13: error: invalid storage class >> for function 'rx_event_task' static void rx_event_task(unsigned long dev) ^ >> drivers/staging/ks7010/ks7010_sdio.c:396:13: error: invalid storage class >> for function 'ks_wlan_hw_rx' static void ks_wlan_hw_rx(struct ks_wlan_private *priv, uint16_t size) ^ >> drivers/staging/ks7010/ks7010_sdio.c:452:13: error: invalid storage class >> for function 'ks7010_rw_function' static void ks7010_rw_function(struct work_struct *work) ^~ >> drivers/staging/ks7010/ks7010_sdio.c:522:13: error: invalid storage class >> for function 'ks_sdio_interrupt' static void ks_sdio_interrupt(struct sdio_func *func) ^ >> drivers/staging/ks7010/ks7010_sdio.c:593:12: error: invalid storage class >> for function 'trx_device_init' static int trx_device_init(struct ks_wlan_private *priv) ^~~ >> drivers/staging/ks7010/ks7010_sdio.c:609:13: error: invalid storage class >> for function 'trx_device_exit' static void trx_device_exit(struct ks_wlan_private *priv) ^~~ >> drivers/staging/ks7010/ks7010_sdio.c:625:12: error: invalid storage class >> for function 'ks7010_sdio_update_index' static int ks7010_sdio_update_index(struct ks_wlan_private *priv, u32 index) ^~~~ >> drivers/staging/ks7010/ks7010_sdio.c:652:12: error: invalid storage class >> for function 'ks7010_sdio_data_compare' sta
[PATCH] futex: allow for compiling out PI support
This makes it possible to preserve basic futex support and compile out the PI support when RT mutexes are not available. Signed-off-by: Nicolas Pitre--- include/linux/futex.h | 7 ++- init/Kconfig| 7 ++- kernel/futex.c | 22 ++ kernel/locking/rtmutex_common.h | 29 + 4 files changed, 63 insertions(+), 2 deletions(-) diff --git a/include/linux/futex.h b/include/linux/futex.h index 7c5b694864..f36bfd26f9 100644 --- a/include/linux/futex.h +++ b/include/linux/futex.h @@ -54,7 +54,6 @@ union futex_key { #ifdef CONFIG_FUTEX extern void exit_robust_list(struct task_struct *curr); -extern void exit_pi_state_list(struct task_struct *curr); #ifdef CONFIG_HAVE_FUTEX_CMPXCHG #define futex_cmpxchg_enabled 1 #else @@ -64,8 +63,14 @@ extern int futex_cmpxchg_enabled; static inline void exit_robust_list(struct task_struct *curr) { } +#endif + +#ifdef CONFIG_FUTEX_PI +extern void exit_pi_state_list(struct task_struct *curr); +#else static inline void exit_pi_state_list(struct task_struct *curr) { } #endif + #endif diff --git a/init/Kconfig b/init/Kconfig index 8514b25db2..5f0ef850e8 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1275,12 +1275,17 @@ config BASE_FULL config FUTEX bool "Enable futex support" if EXPERT default y - select RT_MUTEXES + imply RT_MUTEXES help Disabling this option will cause the kernel to be built without support for "fast userspace mutexes". The resulting kernel may not run glibc-based applications correctly. +config FUTEX_PI + bool + depends on FUTEX && RT_MUTEXES + default y + config HAVE_FUTEX_CMPXCHG bool depends on FUTEX diff --git a/kernel/futex.c b/kernel/futex.c index 16dbe4c938..ad0af4df1b 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -875,6 +875,8 @@ static struct task_struct *futex_find_get_task(pid_t pid) return p; } +#ifdef CONFIG_FUTEX_PI + /* * This task is holding PI mutexes at exit time => bad. * Kernel cleans up PI-state, but userspace is likely hosed. @@ -932,6 +934,8 @@ void exit_pi_state_list(struct task_struct *curr) raw_spin_unlock_irq(>pi_lock); } +#endif + /* * We need to check the following states: * @@ -1799,6 +1803,15 @@ static int futex_requeue(u32 __user *uaddr1, unsigned int flags, struct futex_q *this, *next; DEFINE_WAKE_Q(wake_q); + /* +* When PI not supported: return -ENOSYS if requeue_pi is true, +* consequently the compiler knows requeue_pi is always false past +* this point which will optimize away all the conditional code +* further down. +*/ + if (!IS_ENABLED(CONFIG_FUTEX_PI) && requeue_pi) + return -ENOSYS; + if (requeue_pi) { /* * Requeue PI only works on two distinct uaddrs. This @@ -2594,6 +2607,9 @@ static int futex_lock_pi(u32 __user *uaddr, unsigned int flags, struct futex_q q = futex_q_init; int res, ret; + if (!IS_ENABLED(CONFIG_FUTEX_PI)) + return -ENOSYS; + if (refill_pi_state_cache()) return -ENOMEM; @@ -2773,6 +2789,9 @@ static int futex_unlock_pi(u32 __user *uaddr, unsigned int flags) struct futex_q *top_waiter; int ret; + if (!IS_ENABLED(CONFIG_FUTEX_PI)) + return -ENOSYS; + retry: if (get_user(uval, uaddr)) return -EFAULT; @@ -2983,6 +3002,9 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags, struct futex_q q = futex_q_init; int res, ret; + if (!IS_ENABLED(CONFIG_FUTEX_PI)) + return -ENOSYS; + if (uaddr == uaddr2) return -EINVAL; diff --git a/kernel/locking/rtmutex_common.h b/kernel/locking/rtmutex_common.h index 72ad45a9a7..8d039b928d 100644 --- a/kernel/locking/rtmutex_common.h +++ b/kernel/locking/rtmutex_common.h @@ -40,6 +40,9 @@ struct rt_mutex_waiter { /* * Various helpers to access the waiters-tree: */ + +#ifdef CONFIG_RT_MUTEXES + static inline int rt_mutex_has_waiters(struct rt_mutex *lock) { return !RB_EMPTY_ROOT(>waiters); @@ -69,6 +72,32 @@ task_top_pi_waiter(struct task_struct *p) pi_tree_entry); } +#else + +static inline int rt_mutex_has_waiters(struct rt_mutex *lock) +{ + return false; +} + +static inline struct rt_mutex_waiter * +rt_mutex_top_waiter(struct rt_mutex *lock) +{ + return NULL; +} + +static inline int task_has_pi_waiters(struct task_struct *p) +{ + return false; +} + +static inline struct rt_mutex_waiter * +task_top_pi_waiter(struct task_struct *p) +{ + return NULL; +} + +#endif + /* * lock->owner state tracking: */
[PATCH] futex: allow for compiling out PI support
This makes it possible to preserve basic futex support and compile out the PI support when RT mutexes are not available. Signed-off-by: Nicolas Pitre --- include/linux/futex.h | 7 ++- init/Kconfig| 7 ++- kernel/futex.c | 22 ++ kernel/locking/rtmutex_common.h | 29 + 4 files changed, 63 insertions(+), 2 deletions(-) diff --git a/include/linux/futex.h b/include/linux/futex.h index 7c5b694864..f36bfd26f9 100644 --- a/include/linux/futex.h +++ b/include/linux/futex.h @@ -54,7 +54,6 @@ union futex_key { #ifdef CONFIG_FUTEX extern void exit_robust_list(struct task_struct *curr); -extern void exit_pi_state_list(struct task_struct *curr); #ifdef CONFIG_HAVE_FUTEX_CMPXCHG #define futex_cmpxchg_enabled 1 #else @@ -64,8 +63,14 @@ extern int futex_cmpxchg_enabled; static inline void exit_robust_list(struct task_struct *curr) { } +#endif + +#ifdef CONFIG_FUTEX_PI +extern void exit_pi_state_list(struct task_struct *curr); +#else static inline void exit_pi_state_list(struct task_struct *curr) { } #endif + #endif diff --git a/init/Kconfig b/init/Kconfig index 8514b25db2..5f0ef850e8 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1275,12 +1275,17 @@ config BASE_FULL config FUTEX bool "Enable futex support" if EXPERT default y - select RT_MUTEXES + imply RT_MUTEXES help Disabling this option will cause the kernel to be built without support for "fast userspace mutexes". The resulting kernel may not run glibc-based applications correctly. +config FUTEX_PI + bool + depends on FUTEX && RT_MUTEXES + default y + config HAVE_FUTEX_CMPXCHG bool depends on FUTEX diff --git a/kernel/futex.c b/kernel/futex.c index 16dbe4c938..ad0af4df1b 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -875,6 +875,8 @@ static struct task_struct *futex_find_get_task(pid_t pid) return p; } +#ifdef CONFIG_FUTEX_PI + /* * This task is holding PI mutexes at exit time => bad. * Kernel cleans up PI-state, but userspace is likely hosed. @@ -932,6 +934,8 @@ void exit_pi_state_list(struct task_struct *curr) raw_spin_unlock_irq(>pi_lock); } +#endif + /* * We need to check the following states: * @@ -1799,6 +1803,15 @@ static int futex_requeue(u32 __user *uaddr1, unsigned int flags, struct futex_q *this, *next; DEFINE_WAKE_Q(wake_q); + /* +* When PI not supported: return -ENOSYS if requeue_pi is true, +* consequently the compiler knows requeue_pi is always false past +* this point which will optimize away all the conditional code +* further down. +*/ + if (!IS_ENABLED(CONFIG_FUTEX_PI) && requeue_pi) + return -ENOSYS; + if (requeue_pi) { /* * Requeue PI only works on two distinct uaddrs. This @@ -2594,6 +2607,9 @@ static int futex_lock_pi(u32 __user *uaddr, unsigned int flags, struct futex_q q = futex_q_init; int res, ret; + if (!IS_ENABLED(CONFIG_FUTEX_PI)) + return -ENOSYS; + if (refill_pi_state_cache()) return -ENOMEM; @@ -2773,6 +2789,9 @@ static int futex_unlock_pi(u32 __user *uaddr, unsigned int flags) struct futex_q *top_waiter; int ret; + if (!IS_ENABLED(CONFIG_FUTEX_PI)) + return -ENOSYS; + retry: if (get_user(uval, uaddr)) return -EFAULT; @@ -2983,6 +3002,9 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags, struct futex_q q = futex_q_init; int res, ret; + if (!IS_ENABLED(CONFIG_FUTEX_PI)) + return -ENOSYS; + if (uaddr == uaddr2) return -EINVAL; diff --git a/kernel/locking/rtmutex_common.h b/kernel/locking/rtmutex_common.h index 72ad45a9a7..8d039b928d 100644 --- a/kernel/locking/rtmutex_common.h +++ b/kernel/locking/rtmutex_common.h @@ -40,6 +40,9 @@ struct rt_mutex_waiter { /* * Various helpers to access the waiters-tree: */ + +#ifdef CONFIG_RT_MUTEXES + static inline int rt_mutex_has_waiters(struct rt_mutex *lock) { return !RB_EMPTY_ROOT(>waiters); @@ -69,6 +72,32 @@ task_top_pi_waiter(struct task_struct *p) pi_tree_entry); } +#else + +static inline int rt_mutex_has_waiters(struct rt_mutex *lock) +{ + return false; +} + +static inline struct rt_mutex_waiter * +rt_mutex_top_waiter(struct rt_mutex *lock) +{ + return NULL; +} + +static inline int task_has_pi_waiters(struct task_struct *p) +{ + return false; +} + +static inline struct rt_mutex_waiter * +task_top_pi_waiter(struct task_struct *p) +{ + return NULL; +} + +#endif + /* * lock->owner state tracking: */
[PATCH v3] serio: PS/2 gpio bit banging driver for the serio bus
This driver provides PS/2 serio bus support by implementing bit banging with the GPIO API. The GPIO pins, data and clock, can be configured with a node in the device tree or by static platform data. Writing to a device is supported as well, though it is not recommended as the timings to be halt given by libps2 are very tough and difficult to reach with bit banging. Therefore it can be configured (also in DT and pdata) whether the serio write function should be available for clients. This driver is for development purposes and not for productive use. However, this driver can be useful e.g. when no USB port is available or using old peripherals is desired as PS/2 controller chips getting rare. This driver was tested on a RPI1 and on Hikey960 and it worked well together with the atkbd driver. Signed-off-by: Danilo Krummrich--- v2: Removed one verbose print statement, changed another one to dev_dbg. v3: - fixed compiler warning on blackfin - depends on GPIOLIB - clarify documentation --- .../devicetree/bindings/serio/ps2-gpio.txt | 20 + Documentation/gpio/drivers-on-gpio.txt | 5 + drivers/input/serio/Kconfig| 11 + drivers/input/serio/Makefile | 1 + drivers/input/serio/ps2-gpio.c | 439 + include/linux/ps2-gpio.h | 27 ++ 6 files changed, 503 insertions(+) create mode 100644 Documentation/devicetree/bindings/serio/ps2-gpio.txt create mode 100644 drivers/input/serio/ps2-gpio.c create mode 100644 include/linux/ps2-gpio.h diff --git a/Documentation/devicetree/bindings/serio/ps2-gpio.txt b/Documentation/devicetree/bindings/serio/ps2-gpio.txt new file mode 100644 index 000..828a5b6 --- /dev/null +++ b/Documentation/devicetree/bindings/serio/ps2-gpio.txt @@ -0,0 +1,20 @@ +Device-Tree bindings for ps2 gpio driver + +Required properties: + - compatible = "ps2-gpio"; + - gpios: data and clock gpio + +Optional properties: + - ps2-gpio,write-enable: Indicates whether write function is provided + to serio device. Most probably providing the write fn will not work, + because of the tough timing libps2 requires. + +Example nodes: + +ps2@0 { + compatible = "ps2-gpio"; + gpios = < 24 0 /* data */ + 23 0 /* clock */ + >; + i2c-gpio,write-enable = <0>; +}; diff --git a/Documentation/gpio/drivers-on-gpio.txt b/Documentation/gpio/drivers-on-gpio.txt index 3065132..97c8716 100644 --- a/Documentation/gpio/drivers-on-gpio.txt +++ b/Documentation/gpio/drivers-on-gpio.txt @@ -84,6 +84,11 @@ hardware descriptions such as device tree or ACPI: NAND flash MTD subsystem and provides chip access and partition parsing like any other NAND driving hardware. +- ps2-gpio: drivers/input/serio/ps2-gpio.c is used to drive an PS/2 (IBM) serio + bus, data and clock line, by bit banging two GPIO lines. It will appear as + any other serio bus to the system and makes it possible to connect drivers + for e.g. keyboards and other PS/2 protocol based devices. + Apart from this there are special GPIO drivers in subsystems like MMC/SD to read card detect and write protect GPIO lines, and in the TTY serial subsystem to emulate MCTRL (modem control) signals CTS/RTS by using two GPIO lines. The diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig index c3d05b4..292d6e2 100644 --- a/drivers/input/serio/Kconfig +++ b/drivers/input/serio/Kconfig @@ -292,6 +292,17 @@ config SERIO_SUN4I_PS2 To compile this driver as a module, choose M here: the module will be called sun4i-ps2. +config SERIO_GPIO_PS2 + tristate "GPIO PS/2 bit banging driver" + depends on GPIOLIB + help + Say Y here if you want PS/2 bit banging support via GPIO. + + To compile this driver as a module, choose M here: the + module will be called gpio-ps2. + + If you are unsure, say N. + config USERIO tristate "User space serio port driver support" help diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile index 2374ef9..767bd9b 100644 --- a/drivers/input/serio/Makefile +++ b/drivers/input/serio/Makefile @@ -30,4 +30,5 @@ obj-$(CONFIG_SERIO_APBPS2)+= apbps2.o obj-$(CONFIG_SERIO_OLPC_APSP) += olpc_apsp.o obj-$(CONFIG_HYPERV_KEYBOARD) += hyperv-keyboard.o obj-$(CONFIG_SERIO_SUN4I_PS2) += sun4i-ps2.o +obj-$(CONFIG_SERIO_GPIO_PS2) += ps2-gpio.o obj-$(CONFIG_USERIO) += userio.o diff --git a/drivers/input/serio/ps2-gpio.c b/drivers/input/serio/ps2-gpio.c new file mode 100644 index 000..fc5368b --- /dev/null +++ b/drivers/input/serio/ps2-gpio.c @@ -0,0 +1,439 @@ +/* + * GPIO based serio bus driver for bit banging the PS/2 protocol + * + * Author: Danilo Krummrich + * + * This program is free software; you can redistribute it and/or modify + *
[PATCH v3] serio: PS/2 gpio bit banging driver for the serio bus
This driver provides PS/2 serio bus support by implementing bit banging with the GPIO API. The GPIO pins, data and clock, can be configured with a node in the device tree or by static platform data. Writing to a device is supported as well, though it is not recommended as the timings to be halt given by libps2 are very tough and difficult to reach with bit banging. Therefore it can be configured (also in DT and pdata) whether the serio write function should be available for clients. This driver is for development purposes and not for productive use. However, this driver can be useful e.g. when no USB port is available or using old peripherals is desired as PS/2 controller chips getting rare. This driver was tested on a RPI1 and on Hikey960 and it worked well together with the atkbd driver. Signed-off-by: Danilo Krummrich --- v2: Removed one verbose print statement, changed another one to dev_dbg. v3: - fixed compiler warning on blackfin - depends on GPIOLIB - clarify documentation --- .../devicetree/bindings/serio/ps2-gpio.txt | 20 + Documentation/gpio/drivers-on-gpio.txt | 5 + drivers/input/serio/Kconfig| 11 + drivers/input/serio/Makefile | 1 + drivers/input/serio/ps2-gpio.c | 439 + include/linux/ps2-gpio.h | 27 ++ 6 files changed, 503 insertions(+) create mode 100644 Documentation/devicetree/bindings/serio/ps2-gpio.txt create mode 100644 drivers/input/serio/ps2-gpio.c create mode 100644 include/linux/ps2-gpio.h diff --git a/Documentation/devicetree/bindings/serio/ps2-gpio.txt b/Documentation/devicetree/bindings/serio/ps2-gpio.txt new file mode 100644 index 000..828a5b6 --- /dev/null +++ b/Documentation/devicetree/bindings/serio/ps2-gpio.txt @@ -0,0 +1,20 @@ +Device-Tree bindings for ps2 gpio driver + +Required properties: + - compatible = "ps2-gpio"; + - gpios: data and clock gpio + +Optional properties: + - ps2-gpio,write-enable: Indicates whether write function is provided + to serio device. Most probably providing the write fn will not work, + because of the tough timing libps2 requires. + +Example nodes: + +ps2@0 { + compatible = "ps2-gpio"; + gpios = < 24 0 /* data */ + 23 0 /* clock */ + >; + i2c-gpio,write-enable = <0>; +}; diff --git a/Documentation/gpio/drivers-on-gpio.txt b/Documentation/gpio/drivers-on-gpio.txt index 3065132..97c8716 100644 --- a/Documentation/gpio/drivers-on-gpio.txt +++ b/Documentation/gpio/drivers-on-gpio.txt @@ -84,6 +84,11 @@ hardware descriptions such as device tree or ACPI: NAND flash MTD subsystem and provides chip access and partition parsing like any other NAND driving hardware. +- ps2-gpio: drivers/input/serio/ps2-gpio.c is used to drive an PS/2 (IBM) serio + bus, data and clock line, by bit banging two GPIO lines. It will appear as + any other serio bus to the system and makes it possible to connect drivers + for e.g. keyboards and other PS/2 protocol based devices. + Apart from this there are special GPIO drivers in subsystems like MMC/SD to read card detect and write protect GPIO lines, and in the TTY serial subsystem to emulate MCTRL (modem control) signals CTS/RTS by using two GPIO lines. The diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig index c3d05b4..292d6e2 100644 --- a/drivers/input/serio/Kconfig +++ b/drivers/input/serio/Kconfig @@ -292,6 +292,17 @@ config SERIO_SUN4I_PS2 To compile this driver as a module, choose M here: the module will be called sun4i-ps2. +config SERIO_GPIO_PS2 + tristate "GPIO PS/2 bit banging driver" + depends on GPIOLIB + help + Say Y here if you want PS/2 bit banging support via GPIO. + + To compile this driver as a module, choose M here: the + module will be called gpio-ps2. + + If you are unsure, say N. + config USERIO tristate "User space serio port driver support" help diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile index 2374ef9..767bd9b 100644 --- a/drivers/input/serio/Makefile +++ b/drivers/input/serio/Makefile @@ -30,4 +30,5 @@ obj-$(CONFIG_SERIO_APBPS2)+= apbps2.o obj-$(CONFIG_SERIO_OLPC_APSP) += olpc_apsp.o obj-$(CONFIG_HYPERV_KEYBOARD) += hyperv-keyboard.o obj-$(CONFIG_SERIO_SUN4I_PS2) += sun4i-ps2.o +obj-$(CONFIG_SERIO_GPIO_PS2) += ps2-gpio.o obj-$(CONFIG_USERIO) += userio.o diff --git a/drivers/input/serio/ps2-gpio.c b/drivers/input/serio/ps2-gpio.c new file mode 100644 index 000..fc5368b --- /dev/null +++ b/drivers/input/serio/ps2-gpio.c @@ -0,0 +1,439 @@ +/* + * GPIO based serio bus driver for bit banging the PS/2 protocol + * + * Author: Danilo Krummrich + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2
Re: linux-next: manual merge of the rcu tree with the tip tree
- On Aug 1, 2017, at 12:03 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: > On Tue, Aug 01, 2017 at 12:04:05AM +, Mathieu Desnoyers wrote: >> - On Jul 31, 2017, at 12:13 PM, Paul E. McKenney >> paul...@linux.vnet.ibm.com >> wrote: >> >> > On Mon, Jul 31, 2017 at 01:50:29PM +1000, Stephen Rothwell wrote: >> >> Hi Paul, >> >> >> >> Today's linux-next merge of the rcu tree got a conflict in: >> >> >> >> arch/x86/mm/tlb.c >> >> >> >> between commit: >> >> >> >> 94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking") >> >> >> >> from the tip tree and commit: >> >> >> >> d7713e8f8b23 ("membarrier: Expedited private command") >> >> >> >> from the rcu tree. >> >> >> >> I fixed it up (the former removed the comment and the load_cr3(), so I >> >> just dropped the commend change in the latter) and can carry the fix as >> >> necessary. This is now fixed as far as linux-next is concerned, but any >> >> non trivial conflicts should be mentioned to your upstream maintainer >> >> when your tree is submitted for merging. You may also want to consider >> >> cooperating with the maintainer of the conflicting tree to minimise any >> >> particularly complex conflicts. >> > >> > Thank you, Stephen! >> > >> > Mathieu, Peter, our commit log reads as if removal of load_cr3() would >> > simply result in relying on the ordering provided by the atomic ops >> > in switch_mm() for mm_cpumask(), so that only the commit log and the >> > comment need changing. >> > >> > Please let me know if I am missing something here. >> >> I think you are right. Both load_cr3() and mm_cpumask update operations >> (LOCK prefixed) provide the appropriate barriers on x86. So it's just a >> matter of adapting the comment to the new reality. > > Like this? The updated comment in the commit message looks good, but I would be tempted to add a comment in x86 switch_mm_irqs_off() stating the following requirement just before the line invoking cpumask_set_cpu(): /* * The full memory barrier implied by mm_cpumask update operations * is required by the membarrier system call. */ Thanks, Mathieu > > Thanx, Paul > > > > commit fde19879b6bd1abc0c1d4d5f945efed61bf7eb8c > Author: Mathieu Desnoyers> Date: Fri Jul 28 16:40:40 2017 -0400 > >membarrier: Expedited private command > >Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built >from all runqueues for which current thread's mm is the same as the >thread calling sys_membarrier. It executes faster than the non-expedited >variant (no blocking). It also works on NOHZ_FULL configurations. > >Scheduler-wise, it requires a memory barrier before and after context >switching between processes (which have different mm). The memory >barrier before context switch is already present. For the barrier after >context switch: > >* Our TSO archs can do RELEASE without being a full barrier. Look at > x86 spin_unlock() being a regular STORE for example. But for those > archs, all atomics imply smp_mb and all of them have atomic ops in > switch_mm() for mm_cpumask(). > >* From all weakly ordered machines, only ARM64 and PPC can do RELEASE, > the rest does indeed do smp_mb(), so there the spin_unlock() is a full > barrier and we're good. > >* ARM64 has a very heavy barrier in switch_to(), which suffices. > >* PPC just removed its barrier from switch_to(), but appears to be > talking about adding something to switch_mm(). So add a > smp_mb__after_unlock_lock() for now, until this is settled on the PPC > side. > >Changes since v3: >- Properly document the memory barriers provided by each architecture. > >Changes since v2: >- Address comments from Peter Zijlstra, >- Add smp_mb__after_unlock_lock() after finish_lock_switch() in > finish_task_switch() to add the memory barrier we need after storing > to rq->curr. This is much simpler than the previous approach relying > on atomic_dec_and_test() in mmdrop(), which actually added a memory > barrier in the common case of switching between userspace processes. >- Return -EINVAL when MEMBARRIER_CMD_SHARED is used on a nohz_full > kernel, rather than having the whole membarrier system call returning > -ENOSYS. Indeed, CMD_PRIVATE_EXPEDITED is compatible with nohz_full. > Adapt the CMD_QUERY mask accordingly. > >Changes since v1: >- move membarrier code under kernel/sched/ because it uses the > scheduler runqueue, >- only add the barrier when we switch from a kernel thread. The case > where we switch from a user-space thread is already handled by > the atomic_dec_and_test() in mmdrop(). >- add a comment to mmdrop() documenting the
Re: linux-next: manual merge of the rcu tree with the tip tree
- On Aug 1, 2017, at 12:03 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: > On Tue, Aug 01, 2017 at 12:04:05AM +, Mathieu Desnoyers wrote: >> - On Jul 31, 2017, at 12:13 PM, Paul E. McKenney >> paul...@linux.vnet.ibm.com >> wrote: >> >> > On Mon, Jul 31, 2017 at 01:50:29PM +1000, Stephen Rothwell wrote: >> >> Hi Paul, >> >> >> >> Today's linux-next merge of the rcu tree got a conflict in: >> >> >> >> arch/x86/mm/tlb.c >> >> >> >> between commit: >> >> >> >> 94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking") >> >> >> >> from the tip tree and commit: >> >> >> >> d7713e8f8b23 ("membarrier: Expedited private command") >> >> >> >> from the rcu tree. >> >> >> >> I fixed it up (the former removed the comment and the load_cr3(), so I >> >> just dropped the commend change in the latter) and can carry the fix as >> >> necessary. This is now fixed as far as linux-next is concerned, but any >> >> non trivial conflicts should be mentioned to your upstream maintainer >> >> when your tree is submitted for merging. You may also want to consider >> >> cooperating with the maintainer of the conflicting tree to minimise any >> >> particularly complex conflicts. >> > >> > Thank you, Stephen! >> > >> > Mathieu, Peter, our commit log reads as if removal of load_cr3() would >> > simply result in relying on the ordering provided by the atomic ops >> > in switch_mm() for mm_cpumask(), so that only the commit log and the >> > comment need changing. >> > >> > Please let me know if I am missing something here. >> >> I think you are right. Both load_cr3() and mm_cpumask update operations >> (LOCK prefixed) provide the appropriate barriers on x86. So it's just a >> matter of adapting the comment to the new reality. > > Like this? The updated comment in the commit message looks good, but I would be tempted to add a comment in x86 switch_mm_irqs_off() stating the following requirement just before the line invoking cpumask_set_cpu(): /* * The full memory barrier implied by mm_cpumask update operations * is required by the membarrier system call. */ Thanks, Mathieu > > Thanx, Paul > > > > commit fde19879b6bd1abc0c1d4d5f945efed61bf7eb8c > Author: Mathieu Desnoyers > Date: Fri Jul 28 16:40:40 2017 -0400 > >membarrier: Expedited private command > >Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built >from all runqueues for which current thread's mm is the same as the >thread calling sys_membarrier. It executes faster than the non-expedited >variant (no blocking). It also works on NOHZ_FULL configurations. > >Scheduler-wise, it requires a memory barrier before and after context >switching between processes (which have different mm). The memory >barrier before context switch is already present. For the barrier after >context switch: > >* Our TSO archs can do RELEASE without being a full barrier. Look at > x86 spin_unlock() being a regular STORE for example. But for those > archs, all atomics imply smp_mb and all of them have atomic ops in > switch_mm() for mm_cpumask(). > >* From all weakly ordered machines, only ARM64 and PPC can do RELEASE, > the rest does indeed do smp_mb(), so there the spin_unlock() is a full > barrier and we're good. > >* ARM64 has a very heavy barrier in switch_to(), which suffices. > >* PPC just removed its barrier from switch_to(), but appears to be > talking about adding something to switch_mm(). So add a > smp_mb__after_unlock_lock() for now, until this is settled on the PPC > side. > >Changes since v3: >- Properly document the memory barriers provided by each architecture. > >Changes since v2: >- Address comments from Peter Zijlstra, >- Add smp_mb__after_unlock_lock() after finish_lock_switch() in > finish_task_switch() to add the memory barrier we need after storing > to rq->curr. This is much simpler than the previous approach relying > on atomic_dec_and_test() in mmdrop(), which actually added a memory > barrier in the common case of switching between userspace processes. >- Return -EINVAL when MEMBARRIER_CMD_SHARED is used on a nohz_full > kernel, rather than having the whole membarrier system call returning > -ENOSYS. Indeed, CMD_PRIVATE_EXPEDITED is compatible with nohz_full. > Adapt the CMD_QUERY mask accordingly. > >Changes since v1: >- move membarrier code under kernel/sched/ because it uses the > scheduler runqueue, >- only add the barrier when we switch from a kernel thread. The case > where we switch from a user-space thread is already handled by > the atomic_dec_and_test() in mmdrop(). >- add a comment to mmdrop() documenting the requirement on the implicit >
Re: [PATCH] futex: split PI support to a file of its own
On Mon, 31 Jul 2017, Thomas Gleixner wrote: > But I really do not agree with your reasoning about easier to understand > and maintain. I have the dubious pleasure to stare into that code on a > regular base. PI and non PI share a lot of code and it's really not helping > to have two separate files to stare at. That makes following the PI code > even harder than it is already. So I rather like to see that PI code in an > #ifdef block and not split out into its own file. OK. And in fact I think I now managed to keep #ifdef's to a very small number, counting on dead code elimination instead. Please see next patch. > Please provide a diffstat along with the patch next time. Hmmm... was supposed to be there. For the record it was: include/linux/futex.h |7 +- init/Kconfig |7 +- kernel/futex.c| 1559 +- kernel/futex_pi.c | 1563 +++ 4 files changed, 1598 insertions(+), 1538 deletions(-) Admitedly not small. But when PI is disabled then futex.o shrinks by roughly the half of its original size. So a lot of code is dedicated to PI. Nicolas
Re: [PATCH] futex: split PI support to a file of its own
On Mon, 31 Jul 2017, Thomas Gleixner wrote: > But I really do not agree with your reasoning about easier to understand > and maintain. I have the dubious pleasure to stare into that code on a > regular base. PI and non PI share a lot of code and it's really not helping > to have two separate files to stare at. That makes following the PI code > even harder than it is already. So I rather like to see that PI code in an > #ifdef block and not split out into its own file. OK. And in fact I think I now managed to keep #ifdef's to a very small number, counting on dead code elimination instead. Please see next patch. > Please provide a diffstat along with the patch next time. Hmmm... was supposed to be there. For the record it was: include/linux/futex.h |7 +- init/Kconfig |7 +- kernel/futex.c| 1559 +- kernel/futex_pi.c | 1563 +++ 4 files changed, 1598 insertions(+), 1538 deletions(-) Admitedly not small. But when PI is disabled then futex.o shrinks by roughly the half of its original size. So a lot of code is dedicated to PI. Nicolas
[stable 4.4: PATCH] sched/cputime: Fix prev steal time accouting during CPU hotplug
commit 3d89e5478bf550a50c99e93adf659369798263b0 upstream. Commit: e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug") ... set rq->prev_* to 0 after a CPU hotplug comes back, in order to fix the case where (after CPU hotplug) steal time is smaller than rq->prev_steal_time. However, this should never happen. Steal time was only smaller because of the KVM-specific bug fixed by the previous patch. Worse, the previous patch triggers a bug on CPU hot-unplug/plug operation: because rq->prev_steal_time is cleared, all of the CPU's past steal time will be accounted again on hot-plug. Since the root cause has been fixed, we can just revert commit e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug"). Signed-off-by: Wanpeng LiSigned-off-by: Peter Zijlstra (Intel) Acked-by: Paolo Bonzini Cc: Frederic Weisbecker Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Radim Krčmář Cc: Rik van Riel Cc: Thomas Gleixner Fixes: 'commit e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug")' Link: http://lkml.kernel.org/r/1465813966-3116-3-git-send-email-wanpeng...@hotmail.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andres Oportus --- kernel/sched/core.c | 1 - kernel/sched/sched.h | 13 - 2 files changed, 14 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index c436426..b103b9c 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5553,7 +5553,6 @@ migration_call(struct notifier_block *nfb, unsigned long action, void *hcpu) case CPU_UP_PREPARE: rq->calc_load_update = calc_load_update; - account_reset_rq(rq); break; case CPU_ONLINE: diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index 4e5db65..55d92a1 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -1770,16 +1770,3 @@ static inline u64 irq_time_read(int cpu) } #endif /* CONFIG_64BIT */ #endif /* CONFIG_IRQ_TIME_ACCOUNTING */ - -static inline void account_reset_rq(struct rq *rq) -{ -#ifdef CONFIG_IRQ_TIME_ACCOUNTING - rq->prev_irq_time = 0; -#endif -#ifdef CONFIG_PARAVIRT - rq->prev_steal_time = 0; -#endif -#ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING - rq->prev_steal_time_rq = 0; -#endif -} -- 1.9.1
[stable 4.4: PATCH] sched/cputime: Fix prev steal time accouting during CPU hotplug
commit 3d89e5478bf550a50c99e93adf659369798263b0 upstream. Commit: e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug") ... set rq->prev_* to 0 after a CPU hotplug comes back, in order to fix the case where (after CPU hotplug) steal time is smaller than rq->prev_steal_time. However, this should never happen. Steal time was only smaller because of the KVM-specific bug fixed by the previous patch. Worse, the previous patch triggers a bug on CPU hot-unplug/plug operation: because rq->prev_steal_time is cleared, all of the CPU's past steal time will be accounted again on hot-plug. Since the root cause has been fixed, we can just revert commit e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug"). Signed-off-by: Wanpeng Li Signed-off-by: Peter Zijlstra (Intel) Acked-by: Paolo Bonzini Cc: Frederic Weisbecker Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Radim Krčmář Cc: Rik van Riel Cc: Thomas Gleixner Fixes: 'commit e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug")' Link: http://lkml.kernel.org/r/1465813966-3116-3-git-send-email-wanpeng...@hotmail.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andres Oportus --- kernel/sched/core.c | 1 - kernel/sched/sched.h | 13 - 2 files changed, 14 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index c436426..b103b9c 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5553,7 +5553,6 @@ migration_call(struct notifier_block *nfb, unsigned long action, void *hcpu) case CPU_UP_PREPARE: rq->calc_load_update = calc_load_update; - account_reset_rq(rq); break; case CPU_ONLINE: diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index 4e5db65..55d92a1 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -1770,16 +1770,3 @@ static inline u64 irq_time_read(int cpu) } #endif /* CONFIG_64BIT */ #endif /* CONFIG_IRQ_TIME_ACCOUNTING */ - -static inline void account_reset_rq(struct rq *rq) -{ -#ifdef CONFIG_IRQ_TIME_ACCOUNTING - rq->prev_irq_time = 0; -#endif -#ifdef CONFIG_PARAVIRT - rq->prev_steal_time = 0; -#endif -#ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING - rq->prev_steal_time_rq = 0; -#endif -} -- 1.9.1