Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Resend PATCH V5 3/10] x86/Hyper-v: Add trace in the hyperv_nested_flush_guest_mapping_range()
From: lantianyu1986 @ 2018-12-06 13:21 UTC (permalink / raw)
  Cc: linux-mips, kvm, rkrcmar, catalin.marinas, will.deacon,
	linux-kernel, paulus, hpa, kys, kvmarm, sthemmin, mpe, x86, linux,
	michael.h.kelley, mingo, benh, jhogan, Lan Tianyu, marc.zyngier,
	haiyangz, kvm-ppc, bp, devel, tglx, linux-arm-kernel,
	christoffer.dall, ralf, paul.burton, pbonzini, vkuznets,
	linuxppc-dev
In-Reply-To: <20181206132113.2691-1-Tianyu.Lan@microsoft.com>

From: Lan Tianyu <Tianyu.Lan@microsoft.com>

This patch is to trace log in the hyperv_nested_flush_
guest_mapping_range().

Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
---
 arch/x86/hyperv/nested.c            |  1 +
 arch/x86/include/asm/trace/hyperv.h | 14 ++++++++++++++
 2 files changed, 15 insertions(+)

diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
index 3d0f31e46954..dd0a843f766d 100644
--- a/arch/x86/hyperv/nested.c
+++ b/arch/x86/hyperv/nested.c
@@ -130,6 +130,7 @@ int hyperv_flush_guest_mapping_range(u64 as,
 	else
 		ret = status;
 fault:
+	trace_hyperv_nested_flush_guest_mapping_range(as, ret);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping_range);
diff --git a/arch/x86/include/asm/trace/hyperv.h b/arch/x86/include/asm/trace/hyperv.h
index 2e6245a023ef..ace464f09681 100644
--- a/arch/x86/include/asm/trace/hyperv.h
+++ b/arch/x86/include/asm/trace/hyperv.h
@@ -42,6 +42,20 @@ TRACE_EVENT(hyperv_nested_flush_guest_mapping,
 	    TP_printk("address space %llx ret %d", __entry->as, __entry->ret)
 	);
 
+TRACE_EVENT(hyperv_nested_flush_guest_mapping_range,
+	    TP_PROTO(u64 as, int ret),
+	    TP_ARGS(as, ret),
+
+	    TP_STRUCT__entry(
+		    __field(u64, as)
+		    __field(int, ret)
+		    ),
+	    TP_fast_assign(__entry->as = as;
+			   __entry->ret = ret;
+		    ),
+	    TP_printk("address space %llx ret %d", __entry->as, __entry->ret)
+	);
+
 TRACE_EVENT(hyperv_send_ipi_mask,
 	    TP_PROTO(const struct cpumask *cpus,
 		     int vector),
-- 
2.14.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related
* [Resend PATCH V5 4/10] KVM/VMX: Add hv tlb range flush support
From: lantianyu1986 @ 2018-12-06 13:21 UTC (permalink / raw)
  Cc: linux-mips, kvm, rkrcmar, catalin.marinas, will.deacon,
	christoffer.dall, paulus, hpa, kys, kvmarm, mpe, x86, linux,
	michael.h.kelley, mingo, benh, jhogan, Lan Tianyu, marc.zyngier,
	kvm-ppc, bp, tglx, linux-arm-kernel, linux-kernel, ralf,
	paul.burton, pbonzini, vkuznets, linuxppc-dev
In-Reply-To: <20181206132113.2691-1-Tianyu.Lan@microsoft.com>

From: Lan Tianyu <Tianyu.Lan@microsoft.com>

This patch is to register tlb_remote_flush_with_range callback with
hv tlb range flush interface.

Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
---
Change since v4:
	- Use new function kvm_fill_hv_flush_list_func() to fill flush
       request.
Change since v3:
	- Merge Vitaly's don't pass EPT configuration info to
vmx_hv_remote_flush_tlb() fix.
Change since v1:
	- Pass flush range with new hyper-v tlb flush struct rather
       than KVM tlb flush struct.
---
 arch/x86/kvm/vmx.c | 63 +++++++++++++++++++++++++++++++++++++++---------------
 1 file changed, 46 insertions(+), 17 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 2356118ea440..bad2aa6c5ca1 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1569,7 +1569,34 @@ static void check_ept_pointer_match(struct kvm *kvm)
 	to_kvm_vmx(kvm)->ept_pointers_match = EPT_POINTERS_MATCH;
 }
 
-static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
+int kvm_fill_hv_flush_list_func(struct hv_guest_mapping_flush_list *flush,
+		void *data)
+{
+	struct kvm_tlb_range *range = data;
+
+	return hyperv_fill_flush_guest_mapping_list(flush, range->start_gfn,
+			range->pages);
+}
+
+static inline int __hv_remote_flush_tlb_with_range(struct kvm *kvm,
+		struct kvm_vcpu *vcpu, struct kvm_tlb_range *range)
+{
+	u64 ept_pointer = to_vmx(vcpu)->ept_pointer;
+
+	/*
+	 * FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE hypercall needs address
+	 * of the base of EPT PML4 table, strip off EPT configuration
+	 * information.
+	 */
+	if (range)
+		return hyperv_flush_guest_mapping_range(ept_pointer & PAGE_MASK,
+				kvm_fill_hv_flush_list_func, (void *)range);
+	else
+		return hyperv_flush_guest_mapping(ept_pointer & PAGE_MASK);
+}
+
+static int hv_remote_flush_tlb_with_range(struct kvm *kvm,
+		struct kvm_tlb_range *range)
 {
 	struct kvm_vcpu *vcpu;
 	int ret = -ENOTSUPP, i;
@@ -1579,29 +1606,26 @@ static int vmx_hv_remote_flush_tlb(struct kvm *kvm)
 	if (to_kvm_vmx(kvm)->ept_pointers_match == EPT_POINTERS_CHECK)
 		check_ept_pointer_match(kvm);
 
-	/*
-	 * FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE hypercall needs the address of the
-	 * base of EPT PML4 table, strip off EPT configuration information.
-	 * If ept_pointer is invalid pointer, bypass the flush request.
-	 */
 	if (to_kvm_vmx(kvm)->ept_pointers_match != EPT_POINTERS_MATCH) {
 		kvm_for_each_vcpu(i, vcpu, kvm) {
-			u64 ept_pointer = to_vmx(vcpu)->ept_pointer;
-
-			if (!VALID_PAGE(ept_pointer))
-				continue;
-
-			ret |= hyperv_flush_guest_mapping(
-				ept_pointer & PAGE_MASK);
+			/* If ept_pointer is invalid pointer, bypass flush request. */
+			if (VALID_PAGE(to_vmx(vcpu)->ept_pointer))
+				ret |= __hv_remote_flush_tlb_with_range(
+						kvm, vcpu, range);
 		}
 	} else {
-		ret = hyperv_flush_guest_mapping(
-			to_vmx(kvm_get_vcpu(kvm, 0))->ept_pointer & PAGE_MASK);
+		ret = __hv_remote_flush_tlb_with_range(kvm,
+				kvm_get_vcpu(kvm, 0), range);
 	}
 
 	spin_unlock(&to_kvm_vmx(kvm)->ept_pointer_lock);
 	return ret;
 }
+
+static int hv_remote_flush_tlb(struct kvm *kvm)
+{
+	return hv_remote_flush_tlb_with_range(kvm, NULL);
+}
 #else /* !IS_ENABLED(CONFIG_HYPERV) */
 static inline void evmcs_write64(unsigned long field, u64 value) {}
 static inline void evmcs_write32(unsigned long field, u32 value) {}
@@ -7971,8 +7995,11 @@ static __init int hardware_setup(void)
 
 #if IS_ENABLED(CONFIG_HYPERV)
 	if (ms_hyperv.nested_features & HV_X64_NESTED_GUEST_MAPPING_FLUSH
-	    && enable_ept)
-		kvm_x86_ops->tlb_remote_flush = vmx_hv_remote_flush_tlb;
+	    && enable_ept) {
+		kvm_x86_ops->tlb_remote_flush = hv_remote_flush_tlb;
+		kvm_x86_ops->tlb_remote_flush_with_range =
+				hv_remote_flush_tlb_with_range;
+	}
 #endif
 
 	if (!cpu_has_vmx_ple()) {
@@ -11612,6 +11639,8 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, unsigned int id)
 	vmx->nested.posted_intr_nv = -1;
 	vmx->nested.current_vmptr = -1ull;
 
+	vmx->ept_pointer = INVALID_PAGE;
+
 	vmx->msr_ia32_feature_control_valid_bits = FEATURE_CONTROL_LOCKED;
 
 	/*
-- 
2.14.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related
* [Resend PATCH V5 5/10] KVM/MMU: Add tlb flush with range helper function
From: lantianyu1986 @ 2018-12-06 13:21 UTC (permalink / raw)
  Cc: linux-mips, kvm, rkrcmar, catalin.marinas, will.deacon,
	christoffer.dall, paulus, hpa, kys, kvmarm, mpe, x86, linux,
	michael.h.kelley, mingo, benh, jhogan, Lan Tianyu, marc.zyngier,
	kvm-ppc, bp, tglx, linux-arm-kernel, linux-kernel, ralf,
	paul.burton, pbonzini, vkuznets, linuxppc-dev
In-Reply-To: <20181206132113.2691-1-Tianyu.Lan@microsoft.com>

From: Lan Tianyu <Tianyu.Lan@microsoft.com>

This patch is to add wrapper functions for tlb_remote_flush_with_range
callback and flush tlb directly in kvm_mmu_zap_collapsible_spte().
kvm_mmu_zap_collapsible_spte() returns flush request to the
slot_handle_leaf() and the latter does flush on demand. When
range flush is available, make kvm_mmu_zap_collapsible_spte()
to flush tlb with range directly to avoid returning range back
to slot_handle_leaf().

Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
---
Change since V4:
       Remove flush list interface and flush tlb directly in
       kvm_mmu_zap_collapsible_spte().
Change since V3:
       Remove code of updating "tlbs_dirty"
Change since V2:
       Fix comment in the kvm_flush_remote_tlbs_with_range()
---
 arch/x86/kvm/mmu.c | 37 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 7c03c0f35444..74df957f2f81 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -264,6 +264,35 @@ static void mmu_spte_set(u64 *sptep, u64 spte);
 static union kvm_mmu_page_role
 kvm_mmu_calc_root_page_role(struct kvm_vcpu *vcpu);
 
+
+static inline bool kvm_available_flush_tlb_with_range(void)
+{
+	return kvm_x86_ops->tlb_remote_flush_with_range;
+}
+
+static void kvm_flush_remote_tlbs_with_range(struct kvm *kvm,
+		struct kvm_tlb_range *range)
+{
+	int ret = -ENOTSUPP;
+
+	if (range && kvm_x86_ops->tlb_remote_flush_with_range)
+		ret = kvm_x86_ops->tlb_remote_flush_with_range(kvm, range);
+
+	if (ret)
+		kvm_flush_remote_tlbs(kvm);
+}
+
+static void kvm_flush_remote_tlbs_with_address(struct kvm *kvm,
+		u64 start_gfn, u64 pages)
+{
+	struct kvm_tlb_range range;
+
+	range.start_gfn = start_gfn;
+	range.pages = pages;
+
+	kvm_flush_remote_tlbs_with_range(kvm, &range);
+}
+
 void kvm_mmu_set_mmio_spte_mask(u64 mmio_mask, u64 mmio_value)
 {
 	BUG_ON((mmio_mask & mmio_value) != mmio_value);
@@ -5671,7 +5700,13 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm,
 			!kvm_is_reserved_pfn(pfn) &&
 			PageTransCompoundMap(pfn_to_page(pfn))) {
 			pte_list_remove(rmap_head, sptep);
-			need_tlb_flush = 1;
+
+			if (kvm_available_flush_tlb_with_range())
+				kvm_flush_remote_tlbs_with_address(kvm, sp->gfn,
+					KVM_PAGES_PER_HPAGE(sp->role.level));
+			else
+				need_tlb_flush = 1;
+
 			goto restart;
 		}
 	}
-- 
2.14.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related
* [Resend PATCH V5 6/10] KVM: Replace old tlb flush function with new one to flush a specified range.
From: lantianyu1986 @ 2018-12-06 13:21 UTC (permalink / raw)
  Cc: linux-mips, kvm, rkrcmar, catalin.marinas, will.deacon,
	christoffer.dall, paulus, hpa, kys, kvmarm, mpe, x86, linux,
	michael.h.kelley, mingo, benh, jhogan, Lan Tianyu, marc.zyngier,
	kvm-ppc, bp, tglx, linux-arm-kernel, linux-kernel, ralf,
	paul.burton, pbonzini, vkuznets, linuxppc-dev
In-Reply-To: <20181206132113.2691-1-Tianyu.Lan@microsoft.com>

From: Lan Tianyu <Tianyu.Lan@microsoft.com>

This patch is to replace kvm_flush_remote_tlbs() with kvm_flush_
remote_tlbs_with_address() in some functions without logic change.

Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
---
 arch/x86/kvm/mmu.c         | 31 +++++++++++++++++++++----------
 arch/x86/kvm/paging_tmpl.h |  3 ++-
 2 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 74df957f2f81..1cd3c316a7e6 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1485,8 +1485,12 @@ static bool __drop_large_spte(struct kvm *kvm, u64 *sptep)
 
 static void drop_large_spte(struct kvm_vcpu *vcpu, u64 *sptep)
 {
-	if (__drop_large_spte(vcpu->kvm, sptep))
-		kvm_flush_remote_tlbs(vcpu->kvm);
+	if (__drop_large_spte(vcpu->kvm, sptep)) {
+		struct kvm_mmu_page *sp = page_header(__pa(sptep));
+
+		kvm_flush_remote_tlbs_with_address(vcpu->kvm, sp->gfn,
+			KVM_PAGES_PER_HPAGE(sp->role.level));
+	}
 }
 
 /*
@@ -1954,7 +1958,8 @@ static void rmap_recycle(struct kvm_vcpu *vcpu, u64 *spte, gfn_t gfn)
 	rmap_head = gfn_to_rmap(vcpu->kvm, gfn, sp);
 
 	kvm_unmap_rmapp(vcpu->kvm, rmap_head, NULL, gfn, sp->role.level, 0);
-	kvm_flush_remote_tlbs(vcpu->kvm);
+	kvm_flush_remote_tlbs_with_address(vcpu->kvm, sp->gfn,
+			KVM_PAGES_PER_HPAGE(sp->role.level));
 }
 
 int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end)
@@ -2470,7 +2475,7 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct kvm_vcpu *vcpu,
 		account_shadowed(vcpu->kvm, sp);
 		if (level == PT_PAGE_TABLE_LEVEL &&
 		      rmap_write_protect(vcpu, gfn))
-			kvm_flush_remote_tlbs(vcpu->kvm);
+			kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn, 1);
 
 		if (level > PT_PAGE_TABLE_LEVEL && need_sync)
 			flush |= kvm_sync_pages(vcpu, gfn, &invalid_list);
@@ -2590,7 +2595,7 @@ static void validate_direct_spte(struct kvm_vcpu *vcpu, u64 *sptep,
 			return;
 
 		drop_parent_pte(child, sptep);
-		kvm_flush_remote_tlbs(vcpu->kvm);
+		kvm_flush_remote_tlbs_with_address(vcpu->kvm, child->gfn, 1);
 	}
 }
 
@@ -3014,8 +3019,10 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, u64 *sptep, unsigned pte_access,
 			ret = RET_PF_EMULATE;
 		kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
 	}
+
 	if (set_spte_ret & SET_SPTE_NEED_REMOTE_TLB_FLUSH || flush)
-		kvm_flush_remote_tlbs(vcpu->kvm);
+		kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn,
+				KVM_PAGES_PER_HPAGE(level));
 
 	if (unlikely(is_mmio_spte(*sptep)))
 		ret = RET_PF_EMULATE;
@@ -5672,7 +5679,8 @@ void kvm_mmu_slot_remove_write_access(struct kvm *kvm,
 	 * on PT_WRITABLE_MASK anymore.
 	 */
 	if (flush)
-		kvm_flush_remote_tlbs(kvm);
+		kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+			memslot->npages);
 }
 
 static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm,
@@ -5742,7 +5750,8 @@ void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm,
 	 * dirty_bitmap.
 	 */
 	if (flush)
-		kvm_flush_remote_tlbs(kvm);
+		kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+				memslot->npages);
 }
 EXPORT_SYMBOL_GPL(kvm_mmu_slot_leaf_clear_dirty);
 
@@ -5760,7 +5769,8 @@ void kvm_mmu_slot_largepage_remove_write_access(struct kvm *kvm,
 	lockdep_assert_held(&kvm->slots_lock);
 
 	if (flush)
-		kvm_flush_remote_tlbs(kvm);
+		kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+				memslot->npages);
 }
 EXPORT_SYMBOL_GPL(kvm_mmu_slot_largepage_remove_write_access);
 
@@ -5777,7 +5787,8 @@ void kvm_mmu_slot_set_dirty(struct kvm *kvm,
 
 	/* see kvm_mmu_slot_leaf_clear_dirty */
 	if (flush)
-		kvm_flush_remote_tlbs(kvm);
+		kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn,
+				memslot->npages);
 }
 EXPORT_SYMBOL_GPL(kvm_mmu_slot_set_dirty);
 
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 7cf2185b7eb5..6bdca39829bc 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -894,7 +894,8 @@ static void FNAME(invlpg)(struct kvm_vcpu *vcpu, gva_t gva, hpa_t root_hpa)
 			pte_gpa += (sptep - sp->spt) * sizeof(pt_element_t);
 
 			if (mmu_page_zap_pte(vcpu->kvm, sp, sptep))
-				kvm_flush_remote_tlbs(vcpu->kvm);
+				kvm_flush_remote_tlbs_with_address(vcpu->kvm,
+					sp->gfn, KVM_PAGES_PER_HPAGE(sp->role.level));
 
 			if (!rmap_can_add(vcpu))
 				break;
-- 
2.14.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related
* [Resend PATCH V5 7/10] KVM: Make kvm_set_spte_hva() return int
From: lantianyu1986 @ 2018-12-06 13:21 UTC (permalink / raw)
  Cc: linux-mips, kvm, rkrcmar, catalin.marinas, will.deacon,
	christoffer.dall, paulus, hpa, kys, kvmarm, mpe, x86, linux,
	michael.h.kelley, mingo, benh, jhogan, Lan Tianyu, marc.zyngier,
	kvm-ppc, bp, tglx, linux-arm-kernel, linux-kernel, ralf,
	paul.burton, pbonzini, vkuznets, linuxppc-dev
In-Reply-To: <20181206132113.2691-1-Tianyu.Lan@microsoft.com>

From: Lan Tianyu <Tianyu.Lan@microsoft.com>

The patch is to make kvm_set_spte_hva() return int and caller can
check return value to determine flush tlb or not.

Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
---
 arch/arm/include/asm/kvm_host.h     | 2 +-
 arch/arm64/include/asm/kvm_host.h   | 2 +-
 arch/mips/include/asm/kvm_host.h    | 2 +-
 arch/mips/kvm/mmu.c                 | 3 ++-
 arch/powerpc/include/asm/kvm_host.h | 2 +-
 arch/powerpc/kvm/book3s.c           | 3 ++-
 arch/powerpc/kvm/e500_mmu_host.c    | 3 ++-
 arch/x86/include/asm/kvm_host.h     | 2 +-
 arch/x86/kvm/mmu.c                  | 3 ++-
 virt/kvm/arm/mmu.c                  | 6 ++++--
 10 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 5ca5d9af0c26..fb62b500e590 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -225,7 +225,7 @@ int __kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
 #define KVM_ARCH_WANT_MMU_NOTIFIER
 int kvm_unmap_hva_range(struct kvm *kvm,
 			unsigned long start, unsigned long end);
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
 
 unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
 int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 52fbc823ff8c..b3df7b38ba7d 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -360,7 +360,7 @@ int __kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
 #define KVM_ARCH_WANT_MMU_NOTIFIER
 int kvm_unmap_hva_range(struct kvm *kvm,
 			unsigned long start, unsigned long end);
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
 int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end);
 int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
 
diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
index 2c1c53d12179..71c3f21d80d5 100644
--- a/arch/mips/include/asm/kvm_host.h
+++ b/arch/mips/include/asm/kvm_host.h
@@ -933,7 +933,7 @@ enum kvm_mips_fault_result kvm_trap_emul_gva_fault(struct kvm_vcpu *vcpu,
 #define KVM_ARCH_WANT_MMU_NOTIFIER
 int kvm_unmap_hva_range(struct kvm *kvm,
 			unsigned long start, unsigned long end);
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
 int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end);
 int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
 
diff --git a/arch/mips/kvm/mmu.c b/arch/mips/kvm/mmu.c
index d8dcdb350405..97e538a8c1be 100644
--- a/arch/mips/kvm/mmu.c
+++ b/arch/mips/kvm/mmu.c
@@ -551,7 +551,7 @@ static int kvm_set_spte_handler(struct kvm *kvm, gfn_t gfn, gfn_t gfn_end,
 	       (pte_dirty(old_pte) && !pte_dirty(hva_pte));
 }
 
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
 {
 	unsigned long end = hva + PAGE_SIZE;
 	int ret;
@@ -559,6 +559,7 @@ void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
 	ret = handle_hva_to_gpa(kvm, hva, end, &kvm_set_spte_handler, &pte);
 	if (ret)
 		kvm_mips_callbacks->flush_shadow_all(kvm);
+	return 0;
 }
 
 static int kvm_age_hva_handler(struct kvm *kvm, gfn_t gfn, gfn_t gfn_end,
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index fac6f631ed29..ab23379c53a9 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -72,7 +72,7 @@ extern int kvm_unmap_hva_range(struct kvm *kvm,
 			       unsigned long start, unsigned long end);
 extern int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end);
 extern int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
-extern void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
+extern int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
 
 #define HPTEG_CACHE_NUM			(1 << 15)
 #define HPTEG_HASH_BITS_PTE		13
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index fd9893bc7aa1..437613bb609a 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -850,9 +850,10 @@ int kvm_test_age_hva(struct kvm *kvm, unsigned long hva)
 	return kvm->arch.kvm_ops->test_age_hva(kvm, hva);
 }
 
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
 {
 	kvm->arch.kvm_ops->set_spte_hva(kvm, hva, pte);
+	return 0;
 }
 
 void kvmppc_mmu_destroy(struct kvm_vcpu *vcpu)
diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
index 8f2985e46f6f..c3f312b2bcb3 100644
--- a/arch/powerpc/kvm/e500_mmu_host.c
+++ b/arch/powerpc/kvm/e500_mmu_host.c
@@ -757,10 +757,11 @@ int kvm_test_age_hva(struct kvm *kvm, unsigned long hva)
 	return 0;
 }
 
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
 {
 	/* The page will get remapped properly on its next fault */
 	kvm_unmap_hva(kvm, hva);
+	return 0;
 }
 
 /*****************************************/
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index fc7513ecfc13..d3bdeda92e89 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1510,7 +1510,7 @@ asmlinkage void kvm_spurious_fault(void);
 int kvm_unmap_hva_range(struct kvm *kvm, unsigned long start, unsigned long end);
 int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end);
 int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
 int kvm_cpu_has_injectable_intr(struct kvm_vcpu *v);
 int kvm_cpu_has_interrupt(struct kvm_vcpu *vcpu);
 int kvm_arch_interrupt_allowed(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 1cd3c316a7e6..dfef49f1e7a6 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1913,9 +1913,10 @@ int kvm_unmap_hva_range(struct kvm *kvm, unsigned long start, unsigned long end)
 	return kvm_handle_hva_range(kvm, start, end, 0, kvm_unmap_rmapp);
 }
 
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
 {
 	kvm_handle_hva(kvm, hva, (unsigned long)&pte, kvm_set_pte_rmapp);
+	return 0;
 }
 
 static int kvm_age_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index 5eca48bdb1a6..b8b20c033fcf 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -1849,14 +1849,14 @@ static int kvm_set_spte_handler(struct kvm *kvm, gpa_t gpa, u64 size, void *data
 }
 
 
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
+int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
 {
 	unsigned long end = hva + PAGE_SIZE;
 	kvm_pfn_t pfn = pte_pfn(pte);
 	pte_t stage2_pte;
 
 	if (!kvm->arch.pgd)
-		return;
+		return 0;
 
 	trace_kvm_set_spte_hva(hva);
 
@@ -1867,6 +1867,8 @@ void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
 	clean_dcache_guest_page(pfn, PAGE_SIZE);
 	stage2_pte = pfn_pte(pfn, PAGE_S2);
 	handle_hva_to_gpa(kvm, hva, end, &kvm_set_spte_handler, &stage2_pte);
+
+	return 0;
 }
 
 static int kvm_age_hva_handler(struct kvm *kvm, gpa_t gpa, u64 size, void *data)
-- 
2.14.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: media: sun6i: Add A64 CSI compatible (w/ H3 fallback)
From: Jagan Teki @ 2018-12-06 13:23 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard, Rob Herring, Mark Rutland,
	linux-arm-kernel, devicetree, linux-kernel, linux-amarula,
	Michael Trimarchi
  Cc: Jagan Teki

Allwinner A64 CSI has single channel time-multiplexed BT.656
CMOS sensor interface like H3.

Add a compatible string for it with H3 fallback compatible string,
in this case the H3 driver can be used.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- none

 Documentation/devicetree/bindings/media/sun6i-csi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt b/Documentation/devicetree/bindings/media/sun6i-csi.txt
index eb5a14b828d9..5fb6fd4e2c7d 100644
--- a/Documentation/devicetree/bindings/media/sun6i-csi.txt
+++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
@@ -7,6 +7,7 @@ Required properties:
   - compatible: value must be one of:
     * "allwinner,sun6i-a31-csi"
     * "allwinner,sun8i-h3-csi"
+    * "allwinner,sun50i-a64-csi", "allwinner,sun8i-h3-csi"
     * "allwinner,sun8i-v3s-csi"
   - reg: base address and size of the memory-mapped region.
   - interrupts: interrupt associated to this IP
-- 
2.18.0.321.gffc6fa0e3


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related
* Re: [PATCH v11 0/2] Add ThunderX2 SoC Performance Monitoring Unit driver
From: Will Deacon @ 2018-12-06 12:34 UTC (permalink / raw)
  To: Kulkarni, Ganapatrao
  Cc: mark.rutland@arm.com, Nair, Jayachandran, suzuki.poulose@arm.com,
	gklkml16@gmail.com, rdunlap@infradead.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Richter, Robert, Lomovtsev, Vadim, Jan Glauber,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181206115053.7665-1-ganapatrao.kulkarni@cavium.com>

Hi Ganapat,

On Thu, Dec 06, 2018 at 11:51:24AM +0000, Kulkarni, Ganapatrao wrote:
> This patchset adds PMU driver for Cavium's ThunderX2 SoC UNCORE devices.
> The SoC has PMU support in L3 cache controller (L3C) and in the
> DDR4 Memory Controller (DMC).
> 
> 
> v11:
> 	Updated Patch 2 with minor comments.

Thanks. I've pushed this out on my perf/updates branch:

https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=perf/updates

but note that I did make some spelling and formatting changes to the
Documentation patch, as well as removal of the event descriptions (they
should be part of the perf tool, as is done for the other system PMUs).

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply
* [PATCH] thermal: stm32: read factory settings inside stm_thermal_prepare
From: David HERNANDEZ SANCHEZ @ 2018-12-06 13:23 UTC (permalink / raw)
  To: Zhang Rui, Eduardo Valentin, Daniel Lezcano, Rob Herring,
	Mark Rutland, Maxime Coquelin, Alexandre TORGUE
  Cc: devicetree@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org
In-Reply-To: <1544102603-14899-1-git-send-email-david.hernandezsanchez@st.com>

Calling stm_thermal_read_factory_settings before clocking
internal peripheral causes bad register values and makes
temperature computation wrong.

Calling stm_thermal_read_factory_settings inside
stm_thermal_prepare fixes this problem as internal
peripheral is well clocked at this stage.

Signed-off-by: David Hernandez Sanchez <david.hernandezsanchez@st.com>
Fixes: 1d693155 ("thermal: add stm32 thermal driver")

diff --git a/drivers/thermal/st/stm_thermal.c b/drivers/thermal/st/stm_thermal.c
index 47623da..daa1257 100644
--- a/drivers/thermal/st/stm_thermal.c
+++ b/drivers/thermal/st/stm_thermal.c
@@ -532,6 +532,10 @@ static int stm_thermal_prepare(struct stm_thermal_sensor *sensor)
 	if (ret)
 		return ret;
 
+	ret = stm_thermal_read_factory_settings(sensor);
+	if (ret)
+		goto thermal_unprepare;
+
 	ret = stm_thermal_calibration(sensor);
 	if (ret)
 		goto thermal_unprepare;
@@ -636,10 +640,6 @@ static int stm_thermal_probe(struct platform_device *pdev)
 	/* Populate sensor */
 	sensor->base = base;
 
-	ret = stm_thermal_read_factory_settings(sensor);
-	if (ret)
-		return ret;
-
 	sensor->clk = devm_clk_get(&pdev->dev, "pclk");
 	if (IS_ERR(sensor->clk)) {
 		dev_err(&pdev->dev, "%s: failed to fetch PCLK clock\n",
-- 
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related
* [PATCH] thermal: stm32: Fix stm_thermal_read_factory_settings
From: David HERNANDEZ SANCHEZ @ 2018-12-06 13:23 UTC (permalink / raw)
  To: Zhang Rui, Eduardo Valentin, Daniel Lezcano, Rob Herring,
	Mark Rutland, Maxime Coquelin, Alexandre TORGUE
  Cc: devicetree@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org

Adding brackets allows to multiply the register value,
masked by TS1_RAMP_COEFF_MASK, by an ADJUST value
properly and not to multiply ADJUST by register value and
then mask the whole.

Signed-off-by: David Hernandez Sanchez <david.hernandezsanchez@st.com>
Fixes: 1d693155 ("thermal: add stm32 thermal driver")

diff --git a/drivers/thermal/st/stm_thermal.c b/drivers/thermal/st/stm_thermal.c
index daa1257..bbd73c5 100644
--- a/drivers/thermal/st/stm_thermal.c
+++ b/drivers/thermal/st/stm_thermal.c
@@ -241,8 +241,8 @@ static int stm_thermal_read_factory_settings(struct stm_thermal_sensor *sensor)
 		sensor->t0 = TS1_T0_VAL1;
 
 	/* Retrieve fmt0 and put it on Hz */
-	sensor->fmt0 = ADJUST * readl_relaxed(sensor->base + DTS_T0VALR1_OFFSET)
-					      & TS1_FMT0_MASK;
+	sensor->fmt0 = ADJUST * (readl_relaxed(sensor->base +
+				 DTS_T0VALR1_OFFSET) & TS1_FMT0_MASK);
 
 	/* Retrieve ramp coefficient */
 	sensor->ramp_coeff = readl_relaxed(sensor->base + DTS_RAMPVALR_OFFSET) &
-- 
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related
* Re: [PATCH 0/2] meson: Fix IRQ trigger type
From: Jerome Brunet @ 2018-12-06 13:26 UTC (permalink / raw)
  To: Carlo Caione, robh+dt, mark.rutland, khilman, devicetree,
	linux-arm-kernel, linux-amlogic, martin.blumenstingl
In-Reply-To: <20181204160447.27869-1-ccaione@baylibre.com>

On Tue, 2018-12-04 at 16:04 +0000, Carlo Caione wrote:
> The wrong IRQ trigger type for the macirq was causing the connection
> speed to drop after a few hours when stress testing the DUT. The fix
> seems also to fix another long standing issue with EEE.
> 
> The fixes are tested on a AXG board but we think that the same fix is
> valid also for all the others Amlogic SoC families.
> 
> Carlo Caione (2):
>   arm64: dts: meson: Fix IRQ trigger type for macirq
>   arm64: dts: meson: Remove eee-broken-1000t quirk
> 
>  arch/arm/boot/dts/meson.dtsi                        | 2 +-
>  arch/arm/boot/dts/meson8b-odroidc1.dts              | 1 -
>  arch/arm64/boot/dts/amlogic/meson-axg-s400.dts      | 1 -
>  arch/arm64/boot/dts/amlogic/meson-axg.dtsi          | 2 +-
>  arch/arm64/boot/dts/amlogic/meson-gx.dtsi           | 2 +-
>  arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 1 -
>  arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi   | 1 -
>  7 files changed, 3 insertions(+), 7 deletions(-)
> 

Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>

on the S905 odroid-c2 and A113 s400
Tested-by: Jerome Brunet <jbrunet@baylibre.com>



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply
* Re: [PATCH 0/2] meson: Fix IRQ trigger type
From: Jerome Brunet @ 2018-12-06 13:26 UTC (permalink / raw)
  To: Emiliano Ingrassia, Martin Blumenstingl, Carlo Caione
  Cc: mark.rutland, devicetree, khilman, robh+dt, linux-amlogic,
	linux-arm-kernel
In-Reply-To: <20181206124347.GA10676@ingrassia.epigenesys.com>

On Thu, 2018-12-06 at 13:43 +0100, Emiliano Ingrassia wrote:
> Hi all,
> 
> thank you for involving me.
> 
> I applied Carlo's patches[0] on a kernel vanilla 4.19.6
> and tested it with kernel packet generator, monitoring
> bandwidth usage with "nload".
> 
> All tests were conducted on an Odroid-C1+ Rev. 0.4-20150930 board
> with a short ethernet cable directly attached to a laptop with
> 1G ethernet interface, with "nload" running on the board.
> 
> The tests I performed are composed by the following steps:
> 
> 1) Start packet generator with "rate 1000M" on laptop;
> 
> 2) Keep packet generator active on the laptop and
>    start the packet generator on the board with "rate 1000M";
> 
> 3) Stop both packet generators;
> 
> 4) Start packet generator on the board;
> 
> 5) Keep packet generator active on the board and
>    start the packet generator on the laptop.
> 
> 
> Test results without Carlo's patches applied:
> 
> 1) "nload" shows an incoming traffic of ~950Mbps;
> 
> 2) "nload" shows an incoming traffic of ~400Mbps
>    and an outgoing traffic of ~250Mbps;
> 
> 3) "nload" shows 0Mbps both for incoming and outgoing traffic;
> 
> 4) "nload" shows an outgoing traffic of ~950Mbps from the board;
> 
> 5) "nload" shows incoming traffic of 0Mbps
>    and an outgoing traffic of ~950Mbps.
> 
> Applying only the first patch (change mac IRQ type) I got the same results.
> 
> Applying only the second patch (drop eee-broken-1000t) I got the same
> results!
> 
> With both patches applied I got the same results but with an incoming
> traffic
> of ~3Mbps on the board.

Are you sure you did not mix up the result ?
I would expect this kind of drop when only the eee patch is applied.

> 
> Consider that the described tests were performed for a few minutes.
> 
> 
> The tests I performed clearly show that currently the MAC does not
> perform as 1G full-duplex.

Do you really get 1G full duplex w/o any of these patch ?
I would be surprised if they had any meaningful impact on throughput


> I can't say if this depends on the hardware, the driver or
> the IP description in the board's device tree.
> 
> From the results shown above I think that the patches regarding 32 bit
> Meson SoCs should NOT be applied together, but you can consider to apply
> only the second one which remove the "eee-broken-1000t" flag
> from the board MAC IP description.

I would defenitely advise against that.

> In particular, I think that more tests are needed to better understand
> what's happening in the case of Meson8b SoC.
> 
> To better investigate the MAC behaviour on Odroid-C1+, should I use
> the Amlogic development kernel[1]? If yes, what branch should I use?

And bit of background:
The MAC found in all Amlogic SoC we have seen so far comes from Synopsys
(dwmac).

The kernel provided by the vendor use the IRQ type 'EDGE_RISING' for this IP
This means that the HW block is supposed to generate a rising edge on the irq
line every time there is an event. This is opposed to the Type "LEVEL_HIGH"
with keep the irq line high as long as their pending IRQs

Of course, when adding mainline support, we did the same as the vendor without
thinking about it

We started to investigate the network because, after a while, we noticed
severe performance drops on the AXG family: the throughput would drop from
900MBps to 30MBps after somethings 12+ hours of iperf tests.

We noticed that irqs were not triggered anymore. Manually acking the IRQ in
the register would revive the interface. Since the IRQ is supposed to be acked
in the ISR, we were clearly missing IRQs and as a consequence, never acking
them.

All HW using the dwmac out there are using "LEVEL_HIGH", except amlogic.
Changing this fixes the problem.

Now regarding EEE: about 2 years ago, the network would break on the OC-2. We
noticed the EEE was generating a *LOT* of IRQs. Deactivating EEE solved the
problem ... or so we thought. Fact is, it was an un-acked IRQ as well, and we
just made it harder to trigger by disabling EEE.

So applying the EEE patch without the IRQ_LEVEL would clearly be a mistake,
you would be back in the situation we investigated 2 years, with a very
unstable ethernet connection.

Anyways, I have been able to test it on S905 and A113 and I think this series
should applied, at least for the arm64 family ... most likely of all.

If issues persist on meson8, maybe there is something else ? soemthing hidden
before ?

> 
> 
> On Tue, Dec 04, 2018 at 08:59:20PM +0100, Martin Blumenstingl wrote:
> > adding Emiliano because he experienced high packet loss on Odroid-C1
> > without "eee-broken-1000t"
> > 
> > On Tue, Dec 4, 2018 at 5:05 PM Carlo Caione <ccaione@baylibre.com> wrote:
> > > The wrong IRQ trigger type for the macirq was causing the connection
> > > speed to drop after a few hours when stress testing the DUT. The fix
> > > seems also to fix another long standing issue with EEE.
> 
> Carlo, can you describe precisely the tests you conducted
> on your board and the tools used?
> 
> 
> > the other two DesignWare controllers (2x dwc2) are also using
> > IRQ_TYPE_LEVEL_HIGH
> > so this is not unlikely - good job detective!
> > 
> 
> Consider that currently the USB ports do not work correctly.
> In particular, USB pendrive insertion is not recognized at runtime.
> 
> 
> > > The fixes are tested on a AXG board but we think that the same fix is
> > > valid also for all the others Amlogic SoC families.
> > I checked Amlogic's 3.10 kernel for the 32-bit SoCs and it seems they
> > are setting all IRQs to be edge triggered: [0]
> > however, Emiliano reported an issue with IRQ_TYPE_EDGE_RISING for the
> > dwc2 controllers as well. 291f45dd6da5fa6 "ARM: dts: meson: fixing USB
> > support on Meson6, Meson8 and Meson8b" fixed it for him whereas it
> > worked for me with IRQ_TYPE_EDGE_RISING
> > 
> > I find it strange though that Amlogic's buildroot kernel (even the
> > latest buildroot_openlinux_kernel_4.9_fbdev_20180706) uses:
> >   interrupts = <0 8 1>
> > which translates to:
> >   interrupts = <GIC_SPI 8 IRQ_TYPE_EDGE_RISING>
> > 
> > does the datasheet give a hint that this IRQ should be level triggered
> > or did you find out by trial and error?
> > 
> > > Carlo Caione (2):
> > >   arm64: dts: meson: Fix IRQ trigger type for macirq
> > >   arm64: dts: meson: Remove eee-broken-1000t quirk
> > > 
> > >  arch/arm/boot/dts/meson.dtsi                        | 2 +-
> > >  arch/arm/boot/dts/meson8b-odroidc1.dts              | 1 -
> > these two should be in separate patches with "ARM: dts: " as prefix
> > 
> > >  arch/arm64/boot/dts/amlogic/meson-axg-s400.dts      | 1 -
> > >  arch/arm64/boot/dts/amlogic/meson-axg.dtsi          | 2 +-
> > >  arch/arm64/boot/dts/amlogic/meson-gx.dtsi           | 2 +-
> > >  arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 1 -
> > >  arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi   | 1 -
> > >  7 files changed, 3 insertions(+), 7 deletions(-)
> > > 
> > > --
> > > 2.19.1
> > > 
> > 
> > Regards
> > Martin
> > 
> > [0] 
> > https://github.com/endlessm/linux-meson/blob/cd4096c3ff4eb5b8a8a5581bb46508601c5470dc/drivers/irqchip/irq-gic.c#L400
> > 
> > _______________________________________________
> > linux-amlogic mailing list
> > linux-amlogic@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-amlogic
> 
> Best regards,
> 
> Emiliano
> 
> [0] 
> http://lists.infradead.org/pipermail/linux-amlogic/2018-December/009325.html
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git/
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: allwinner: a64: Add pinmux setting for CSI MCLK on PE1
From: Jagan Teki @ 2018-12-06 13:23 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard, Rob Herring, Mark Rutland,
	linux-arm-kernel, devicetree, linux-kernel, linux-amarula,
	Michael Trimarchi
  Cc: Jagan Teki
In-Reply-To: <20181206132306.11843-1-jagan@amarulasolutions.com>

Some camera modules have the SoC feeding a master clock to the sensor
instead of having a standalone crystal. This clock signal is generated
from the clock control unit and output from the CSI MCLK function of
pin PE1.

Add a pinmux setting for it for camera sensors to reference.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- new patch

 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index d7ab0006ebce..902b5238f1dd 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -538,6 +538,11 @@
 				function = "csi0";
 			};
 
+			csi_mclk_pin: csi-mclk {
+				pins = "PE1";
+				function = "csi0";
+			};
+
 			i2c0_pins: i2c0_pins {
 				pins = "PH0", "PH1";
 				function = "i2c0";
-- 
2.18.0.321.gffc6fa0e3


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: allwinner: a64: Add A64 CSI controller
From: Jagan Teki @ 2018-12-06 13:23 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard, Rob Herring, Mark Rutland,
	linux-arm-kernel, devicetree, linux-kernel, linux-amarula,
	Michael Trimarchi
  Cc: Jagan Teki
In-Reply-To: <20181206132306.11843-1-jagan@amarulasolutions.com>

Allwinner A64 CSI controller has similar features as like in
H3, So add support for A64 via H3 fallback.

Also updated CSI_SCLK to use 300MHz via assigned-clocks, since
the default clock 600MHz seems unable to drive the sensor(ov5640)
to capture the image.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- Use CSI_SCLK to 300MHz 

 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 384c417cb7a2..d7ab0006ebce 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -532,6 +532,12 @@
 			interrupt-controller;
 			#interrupt-cells = <3>;
 
+			csi_pins: csi-pins {
+				pins = "PE0", "PE2", "PE3", "PE4", "PE5", "PE6",
+				       "PE7", "PE8", "PE9", "PE10", "PE11";
+				function = "csi0";
+			};
+
 			i2c0_pins: i2c0_pins {
 				pins = "PH0", "PH1";
 				function = "i2c0";
@@ -899,6 +905,23 @@
 			status = "disabled";
 		};
 
+		csi: csi@1cb0000 {
+			compatible = "allwinner,sun50i-a64-csi",
+				     "allwinner,sun8i-h3-csi";
+			reg = <0x01cb0000 0x1000>;
+			interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_CSI>,
+				 <&ccu CLK_CSI_SCLK>,
+				 <&ccu CLK_DRAM_CSI>;
+			clock-names = "bus", "mod", "ram";
+			resets = <&ccu RST_BUS_CSI>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&csi_pins>;
+			assigned-clocks = <&ccu CLK_CSI_SCLK>;
+			assigned-clock-rates = <300000000>;
+			status = "disabled";
+		};
+
 		hdmi: hdmi@1ee0000 {
 			compatible = "allwinner,sun50i-a64-dw-hdmi",
 				     "allwinner,sun8i-a83t-dw-hdmi";
-- 
2.18.0.321.gffc6fa0e3


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related
* Re: [PATCH] thermal: stm32: Fix stm_thermal_read_factory_settings
From: Daniel Lezcano @ 2018-12-06 13:30 UTC (permalink / raw)
  To: David HERNANDEZ SANCHEZ, Zhang Rui, Eduardo Valentin, Rob Herring,
	Mark Rutland, Maxime Coquelin, Alexandre TORGUE
  Cc: devicetree@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org
In-Reply-To: <1544102603-14899-1-git-send-email-david.hernandezsanchez@st.com>

On 06/12/2018 14:23, David HERNANDEZ SANCHEZ wrote:
> Adding brackets allows to multiply the register value,
> masked by TS1_RAMP_COEFF_MASK, by an ADJUST value
> properly and not to multiply ADJUST by register value and
> then mask the whole.
> 
> Signed-off-by: David Hernandez Sanchez <david.hernandezsanchez@st.com>
> Fixes: 1d693155 ("thermal: add stm32 thermal driver")

Usually 'Fixes' comes first in the list.

Other than that:

Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>

> diff --git a/drivers/thermal/st/stm_thermal.c b/drivers/thermal/st/stm_thermal.c
> index daa1257..bbd73c5 100644
> --- a/drivers/thermal/st/stm_thermal.c
> +++ b/drivers/thermal/st/stm_thermal.c
> @@ -241,8 +241,8 @@ static int stm_thermal_read_factory_settings(struct stm_thermal_sensor *sensor)
>  		sensor->t0 = TS1_T0_VAL1;
>  
>  	/* Retrieve fmt0 and put it on Hz */
> -	sensor->fmt0 = ADJUST * readl_relaxed(sensor->base + DTS_T0VALR1_OFFSET)
> -					      & TS1_FMT0_MASK;
> +	sensor->fmt0 = ADJUST * (readl_relaxed(sensor->base +
> +				 DTS_T0VALR1_OFFSET) & TS1_FMT0_MASK);
>  
>  	/* Retrieve ramp coefficient */
>  	sensor->ramp_coeff = readl_relaxed(sensor->base + DTS_RAMPVALR_OFFSET) &
> 


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply
* Re: [PATCH] thermal: stm32: read factory settings inside stm_thermal_prepare
From: Daniel Lezcano @ 2018-12-06 13:32 UTC (permalink / raw)
  To: David HERNANDEZ SANCHEZ, Zhang Rui, Eduardo Valentin, Rob Herring,
	Mark Rutland, Maxime Coquelin, Alexandre TORGUE
  Cc: devicetree@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org
In-Reply-To: <1544102603-14899-2-git-send-email-david.hernandezsanchez@st.com>

On 06/12/2018 14:23, David HERNANDEZ SANCHEZ wrote:
> Calling stm_thermal_read_factory_settings before clocking
> internal peripheral causes bad register values and makes
> temperature computation wrong.
> 
> Calling stm_thermal_read_factory_settings inside
> stm_thermal_prepare fixes this problem as internal
> peripheral is well clocked at this stage.
> 
> Signed-off-by: David Hernandez Sanchez <david.hernandezsanchez@st.com>
> Fixes: 1d693155 ("thermal: add stm32 thermal driver")

Same comment as the first patch.

Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>


> diff --git a/drivers/thermal/st/stm_thermal.c b/drivers/thermal/st/stm_thermal.c
> index 47623da..daa1257 100644
> --- a/drivers/thermal/st/stm_thermal.c
> +++ b/drivers/thermal/st/stm_thermal.c
> @@ -532,6 +532,10 @@ static int stm_thermal_prepare(struct stm_thermal_sensor *sensor)
>  	if (ret)
>  		return ret;
>  
> +	ret = stm_thermal_read_factory_settings(sensor);
> +	if (ret)
> +		goto thermal_unprepare;
> +
>  	ret = stm_thermal_calibration(sensor);
>  	if (ret)
>  		goto thermal_unprepare;
> @@ -636,10 +640,6 @@ static int stm_thermal_probe(struct platform_device *pdev)
>  	/* Populate sensor */
>  	sensor->base = base;
>  
> -	ret = stm_thermal_read_factory_settings(sensor);
> -	if (ret)
> -		return ret;
> -
>  	sensor->clk = devm_clk_get(&pdev->dev, "pclk");
>  	if (IS_ERR(sensor->clk)) {
>  		dev_err(&pdev->dev, "%s: failed to fetch PCLK clock\n",
> 


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply
* Re: Moving ARM dts files
From: Andreas Färber @ 2018-12-06 13:32 UTC (permalink / raw)
  To: Rob Herring, Tom Rini
  Cc: Andrew Lunn, Alexandre Belloni, Tony Lindgren, Linus Walleij,
	Liviu Dudau, Alexander Graf, Masahiro Yamada, Thierry Reding,
	Florian Fainelli, Kevin Hilman, Gregory CLEMENT, Michal Simek,
	Krzysztof Kozlowski, ARM-SoC Maintainers, Joel Stanley,
	Andy Gross, devicetree, Architecture Mailman List, Jason Cooper,
	Simon Horman, LAKML, Grant Likely, Maxime Coquelin, Shawn Guo,
	Daniel Mack
In-Reply-To: <CAL_JsqKO3v0pgVfNhVNOkpZ4sePrybDgZG0riN-tutvwOZ4zYg@mail.gmail.com>

Am 05.12.18 um 05:17 schrieb Rob Herring:
> On Tue, Dec 4, 2018 at 7:22 PM Andreas Färber <afaerber@suse.de> wrote:
>>
>> Rob,
>>
>> Am 04.12.18 um 19:36 schrieb Rob Herring:
>>> I've put together a script to move the dts files and update the
>>> makefiles. It doesn't handle files not following a common prefix which
>>> isn't many and some includes within the dts files will need some fixups
>>> by hand.
>>>
>>> MAINTAINERS will also need updating.
>>>
>>> A few questions:
>>>
>>> Do we want to move absolutely everything to subdirs?
>>
>> This refactoring is a terrible idea!
> 
> How do you really feel?
> 
>> While it would've been nice to have more structure from the start,
>> bootloaders like U-Boot expect a flat structure for arm .dtb files now.
>> If you start installing them into subdirs instead, they won't find the
>> files anymore under the hardcoded name.
>>
>> Doing this only for new platforms would be much less invasive and allow
>> to prepare bootloaders accordingly.
> 
> That was my suggestion where this started for the new RDA platform.
> Olof preferred to move everything and that's my desire too.
> 
>> Alternatively, white-list which ones
>> are safe to move around.
> 
> I'd prefer to know which ones the distros don't want moved. That
> should be easier to figure out. We also need that anyways in context
> of what platforms we care about compatibility.
> 
> Another option is dtbs_install target could flatten the installed
> dtbs. That is the only part the distros should depend on.

I'd be okay with distinguishing source vs. install location. Due to the
issue I mention below (and more) we can't use install_dtbs for openSUSE
and had to reimplement it, which we'd need to (and can) adjust.

>> But don't just script a refactoring because it
>> looks nicer in the source tree, without testing what side effects this
>> can have for board/distro users of the compiled files in practice.
>> We already had that discussion for arm64 because Debian chose to ignore
>> the kernel-installed subdirectories and installed .dtb files into a flat
>> directory, which collided with openSUSE sticking to the kernel choice.
> 
> So everyone already deals with subdirs or not with arm and arm64
> already, seems like they can deal with this. I will raise the topic on
> the cross-distro list though.

Sounds like you're twisting words... The keyword was "hardcoded" paths -
one way or another (not "and") depending on the kernel choices being
flat for arm, vendor subdir for arm64.

>> This topic becomes even more important with EBBR: There is neither a
>> mechanism in place to sync .dts files into U-Boot or EDK2 source trees,
>> nor are capsule updates implemented in U-Boot for easily deploying such
>> bootloaders with new .dts sources or paths yet.
> 
> EBBR actually says firmware (including dtbs) goes in directories named
> by vendor.

Fine, but unrelated.

>> And I can assure you
>> that just getting users to dd the right bootloader can be difficult...
>> Since DT forward and backward compatibility is often being neglected,
>> for example with optional properties or renamed compatibles that break
>> booting with previous drivers, new kernel versions often need updated
>> Device Trees to make use of new/enhanced drivers. Therefore it is
>> unfortunately often enough a necessity to load newer kernel-based .dtb
>> files matching the kernel (as opposed to the dream of kernel-independent
>> hardware descriptions) when working with the latest -rc or -next kernels
>> at least. For examples of DTs needing updates, look no further than
>> Linaro's 96boards - in case of hikey960/EDK2 GRUB is another layer where
>> .dtb paths may be hardcoded, ditto for arm; and Armada was an example
>> where the upstream bindings for the network IP changed incompatibly.
> 
> Compatibility is an issue, yes, but that really has nothing to do with this.
> 
>> DT overlays are another topic that is not making any progress upstream
>> according to the ELCE BoF, so beyond the Raspberry Pi the only known
>> working way to apply them is to write a U-Boot boot.scr script, which
>> can either reuse $fdtcontroladdr DT or use the filename $fdtfile or
>> hardcode one, the latter two of which would break with your renaming.
> 
> DT overlays also have nothing to do with this as there aren't any in
> the kernel. I'm not inclined to take any either with a flat tree.
> We're already at 1800+ files.

Read again: a) Breaking DT changes and b) the desire to use Overlays
instead of replacing the bootloaders for each change are _reasons_ why
people depend on .dtb filenames from the kernel source tree for their
boot flow today. Nothing to do with downstream .dtbo files.

For example, remember when I reported that the kernel didn't compile DTs
with -@? No reaction except for Frank asking to be CC'ed - was it ever
fixed??? Do EDK2's or U-Boot's built-in DTs compile with -@ today?
Raspberry Pi overlays in U-Boot work because it switched to passing the
DT through from the proprietary firmware.
Point being that while it would be nice to get a current, compatible DT
via UEFI tables and ignore .dtb filenames outside of a few bootloaders,
in reality we're not quite there yet for all platforms.

I see no problem (except for naming choices) moving new targets like RDA
to subfolders because we can then hardcode it the new way; I also assume
deeply embedded targets like stm32f4 or targets with no mainline
bootloaders yet like owl-s500 could be refactored.
I do see problems refactoring widely used SBC targets like sunXi though.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply
* Re: Moving ARM dts files
From: Uwe Kleine-König @ 2018-12-06 13:39 UTC (permalink / raw)
  To: Rob Herring
  Cc: Andrew Lunn, Alexandre Belloni, Tony Lindgren, Linus Walleij,
	Liviu Dudau, Masahiro Yamada, Thierry Reding, Florian Fainelli,
	Kevin Hilman, Gregory CLEMENT, Michal Simek, Krzysztof Kozlowski,
	ARM-SoC Maintainers, Joel Stanley, Andy Gross, devicetree,
	Jason Cooper, Simon Horman,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	Jisheng Zhang, Maxime Coquelin, Shawn Guo, Andreas Färber,
	Daniel Mack
In-Reply-To: <CAL_JsqJWnB+EAoXk9a1M_D-kH8kZcwD6gTj0yVa_hBCGapB4RQ@mail.gmail.com>

Hello,

On Wed, Dec 05, 2018 at 09:01:59AM -0600, Rob Herring wrote:
> i.MX23 is a Sigmatel chip STMP??

I think the Freescale i.MX23 didn't exist at Sigmatel back then. AFAIK
this is a new design using IP from Sigmatel after the aquisition.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply
* OMAP4430 SDP with KS8851: very slow networking
From: Russell King - ARM Linux @ 2018-12-06 13:22 UTC (permalink / raw)
  To: linux-arm-kernel, linux-omap, netdev, Tony Lindgren

Hi,

I'm experiencing very slow networking on my OMAP4430 SDP board, which
uses the SPI ethernet chip KS8851.

The initial symptom I noticed is that tftping the 3MB kernel image
inside Linux takes more than 5 minutes.  Running tcpdump on the tftp
server shows:

13:13:29.018377 IP 192.168.1.189.45542 > 192.168.0.4.40620: UDP, length 4
13:13:29.020683 IP 192.168.1.189.45542 > 192.168.0.4.40620: UDP, length 4
13:13:29.022280 IP 192.168.0.4.40620 > 192.168.1.189.45542: UDP, length 516
13:13:29.078391 IP 192.168.1.189.45542 > 192.168.0.4.40620: UDP, length 4
13:13:29.080696 IP 192.168.1.189.45542 > 192.168.0.4.40620: UDP, length 4
13:13:29.082291 IP 192.168.0.4.40620 > 192.168.1.189.45542: UDP, length 516
13:13:29.138377 IP 192.168.1.189.45542 > 192.168.0.4.40620: UDP, length 4
13:13:29.140563 IP 192.168.1.189.45542 > 192.168.0.4.40620: UDP, length 4
13:13:29.142205 IP 192.168.0.4.40620 > 192.168.1.189.45542: UDP, length 516
13:13:29.198365 IP 192.168.1.189.45542 > 192.168.0.4.40620: UDP, length 4
13:13:29.200709 IP 192.168.1.189.45542 > 192.168.0.4.40620: UDP, length 4
13:13:29.202292 IP 192.168.0.4.40620 > 192.168.1.189.45542: UDP, length 516
13:13:29.258375 IP 192.168.1.189.45542 > 192.168.0.4.40620: UDP, length 4
13:13:29.260708 IP 192.168.1.189.45542 > 192.168.0.4.40620: UDP, length 4
13:13:29.262292 IP 192.168.0.4.40620 > 192.168.1.189.45542: UDP, length 516

which is about 512 bytes every 60ms.  The two length 4 UDPs are the
ACK packets - one of which is a repeated transmission for each
packet.

I also see NFS timing out.

pings also have weirdness:

root@omap-4430sdp:~# ping -c 10 192.168.0.4
PING 192.168.0.4 (192.168.0.4): 56 data bytes
64 bytes from 192.168.0.4: seq=0 ttl=64 time=107.635 ms
64 bytes from 192.168.0.4: seq=1 ttl=64 time=1011.689 ms
64 bytes from 192.168.0.4: seq=2 ttl=64 time=5.157 ms
64 bytes from 192.168.0.4: seq=3 ttl=64 time=1021.820 ms
64 bytes from 192.168.0.4: seq=4 ttl=64 time=4.395 ms
64 bytes from 192.168.0.4: seq=5 ttl=64 time=4.669 ms
64 bytes from 192.168.0.4: seq=6 ttl=64 time=371.735 ms
64 bytes from 192.168.0.4: seq=7 ttl=64 time=882.598 ms
64 bytes from 192.168.0.4: seq=8 ttl=64 time=31.372 ms
64 bytes from 192.168.0.4: seq=9 ttl=64 time=2010.772 ms

--- 192.168.0.4 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 4.395/545.184/2010.772 ms

If I ping the board remotely:

$ ping -i .2 192.168.1.189
PING 192.168.1.189 (192.168.1.189) 56(84) bytes of data.
64 bytes from 192.168.1.189: icmp_req=1 ttl=64 time=2033 ms
64 bytes from 192.168.1.189: icmp_req=2 ttl=64 time=1825 ms
64 bytes from 192.168.1.189: icmp_req=3 ttl=64 time=1616 ms
64 bytes from 192.168.1.189: icmp_req=4 ttl=64 time=1417 ms
64 bytes from 192.168.1.189: icmp_req=5 ttl=64 time=1218 ms
64 bytes from 192.168.1.189: icmp_req=6 ttl=64 time=1018 ms
64 bytes from 192.168.1.189: icmp_req=7 ttl=64 time=819 ms
64 bytes from 192.168.1.189: icmp_req=8 ttl=64 time=610 ms
64 bytes from 192.168.1.189: icmp_req=9 ttl=64 time=411 ms
64 bytes from 192.168.1.189: icmp_req=10 ttl=64 time=202 ms
64 bytes from 192.168.1.189: icmp_req=11 ttl=64 time=4.46 ms
64 bytes from 192.168.1.189: icmp_req=12 ttl=64 time=263 ms
64 bytes from 192.168.1.189: icmp_req=13 ttl=64 time=54.5 ms
64 bytes from 192.168.1.189: icmp_req=14 ttl=64 time=1399 ms
64 bytes from 192.168.1.189: icmp_req=15 ttl=64 time=1199 ms
64 bytes from 192.168.1.189: icmp_req=16 ttl=64 time=990 ms
64 bytes from 192.168.1.189: icmp_req=17 ttl=64 time=781 ms
64 bytes from 192.168.1.189: icmp_req=18 ttl=64 time=572 ms
64 bytes from 192.168.1.189: icmp_req=19 ttl=64 time=372 ms
64 bytes from 192.168.1.189: icmp_req=20 ttl=64 time=163 ms
^C
--- 192.168.1.189 ping statistics ---
22 packets transmitted, 20 received, 9% packet loss, time 4302ms
rtt min/avg/max/mdev = 4.468/848.854/2033.873/592.100 ms, pipe 10

It looks very much like a receive problem - in that the board is not
always aware of a packet having been received until it attempts to
transmit (eg, in the case of TFTP, when it re-sends the ACK after a
receive timeout, it _then_ notices that there's a packet waiting.)

I'm not quite sure when this cropped up as I no longer regularly
update and run my nightly boot tests, but I think 4.18 was fine.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: spectre-v2: per-CPU vtables to work around big.Little systems
From: Krzysztof Kozlowski @ 2018-12-06 13:54 UTC (permalink / raw)
  To: linux
  Cc: mark.rutland, julien.thierry, marc.zyngier, will.deacon,
	Morten.Rasmussen, Qais.Yousef, dietmar.eggemann, linux-arm-kernel,
	Marek Szyprowski
In-Reply-To: <20181206123956.GS30658@n2100.armlinux.org.uk>

On Thu, 6 Dec 2018 at 13:40, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
>
> On Thu, Dec 06, 2018 at 11:24:27AM +0100, Krzysztof Kozlowski wrote:
> > On Thu, 6 Dec 2018 at 11:01, Russell King - ARM Linux
> > <linux@armlinux.org.uk> wrote:
> > > I've no idea based on what you've supplied given that the SoC
> > > maintainers are responsible for writing the code to deal with hotplug
> > > etc, and Exynos's code there is something of a maze.  It's not clear
> > > which bits are being used.  I think you at the very least need to debug
> > > to find out whether the problem is at CPU down or CPU up.
> > >
> > > From the ARM architecture point of view, for Cortex A9, all the
> > > processor function instances should be identical.  The only difference
> > > as a result of the patch is that we'll be calling smp_processor_id()
> > > early (which should be fine), and indirecting through the cpu_vtable[]
> > > array rather than merely dereferencing the processor struct.
> > >
> > > What about checking dmesg - messages from offline CPUs do not appear
> > > on the console(s) but are still logged in the kernel log.
> > >
> > > You could try making PROC_VTABLE() the same as PROC_TABLE() (iow,
> > > always access cpu_vtable[0]) to see whether it's the smp_processor_id()
> > > that's causing your problem or not.  If it is, then try and work out
> > > which of the processor functions is causing it by restoring
> > > PROC_VTABLE() and then switching each from PROC_VTABLE() to
> > > PROC_TABLE() until it does work.
> >
> > Thanks for hints!
>
> So I can plan, how long do you think it will take to get some results
> from my suggestions above?

For Suspend to RAM, on v4.20-rc3, this warning appears:
[   84.046722] WARNING: CPU: 1 PID: 0 at
../arch/arm/include/asm/proc-fns.h:124
secondary_start_kernel+0x214/0x26c
(difference between dcache_clean_area)
The secondary CPUs bringup fails with ETIMEDOUT.

Replacing all PROC_VTABLE -> PROC_TABLE improves a little bit - one
secondary CPU comes up, other timeout.
[   58.087004] Enabling non-boot CPUs ...
[   58.089116] ------------[ cut here ]------------
[   58.089138] WARNING: CPU: 1 PID: 0 at
../arch/arm/include/asm/proc-fns.h:124
secondary_start_kernel+0x208/0x264
[   58.089143] Modules linked in:
[   59.084017] CPU1: failed to boot: -110
[   59.085709] Error taking CPU1 up: -110
[   59.087667] ------------[ cut here ]------------
[   59.087683] WARNING: CPU: 2 PID: 0 at
../arch/arm/include/asm/proc-fns.h:126
secondary_start_kernel+0x240/0x264
[   59.087688] Modules linked in:
[   60.086049] CPU2: failed to boot: -110
[   60.086818] Error taking CPU2 up: -110
[   60.091198] CPU3 is up

For hotplug, making CPU online either fails with ETIMEDOUT or with segfault:
[   68.402951] WARNING: CPU: 1 PID: 0 at
../arch/arm/include/asm/proc-fns.h:126
secondary_start_kernel+0x24c/0x26c
[   68.402955] Modules linked in: s5p_cec
[   68.402966] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G        W
  4.20.0-rc3 #149
[   68.402970] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   68.402981] [<c01122f8>] (unwind_backtrace) from [<c010e094>]
(show_stack+0x10/0x14)
[   68.402990] [<c010e094>] (show_stack) from [<c0a3987c>]
(dump_stack+0x98/0xc4)
[   68.402999] [<c0a3987c>] (dump_stack) from [<c0126ccc>] (__warn+0x10c/0x124)
[   68.403008] [<c0126ccc>] (__warn) from [<c0126dfc>]
(warn_slowpath_null+0x40/0x48)
[   68.403017] [<c0126dfc>] (warn_slowpath_null) from [<c0110c1c>]
(secondary_start_kernel+0x24c/0x26c)
[   68.403027] [<c0110c1c>] (secondary_start_kernel) from [<c01109a0>]
(arch_cpu_idle_dead+0x54/0x84)
[   68.403032] irq event stamp: 1028918
[   68.403039] hardirqs last  enabled at (1028917): [<c0a5b7cc>]
_raw_spin_unlock_irqrestore+0x6c/0x74
[   68.403047] hardirqs last disabled at (1028918): [<c0110964>]
arch_cpu_idle_dead+0x18/0x84
[   68.403054] softirqs last  enabled at (1028898): [<c012ecec>]
irq_enter+0x78/0x80
[   68.403061] softirqs last disabled at (1028897): [<c012ecd8>]
irq_enter+0x64/0x80
[   68.403065] ---[ end trace be591873dbd106ff ]---
[   68.403075] Unable to handle kernel paging request at virtual
address e7fddef0
[   68.403082] pgd = 06aec1fd
[   68.403086] [e7fddef0] *pgd=67e1141e(bad)
[   68.403097] Internal error: Oops: 8000000d [#1] PREEMPT SMP ARM
[   68.403103] Modules linked in: s5p_cec
[   68.403114] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G        W
  4.20.0-rc3 #149
[   68.403118] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   68.403124] PC is at 0xe7fddef0
[   68.403131] LR is at secondary_start_kernel+0x98/0x26c
[   68.403137] pc : [<e7fddef0>]    lr : [<c0110a68>]    psr: 200f00d3
[   68.403142] sp : ee925fe8  ip : 00000000  fp : 00000000
[   68.403147] r10: c0d6a088  r9 : c0d6a088  r8 : 4000406a
[   68.403153] r7 : 00000002  r6 : 00000001  r5 : c100c67c  r4 : c1025ab0
[   68.403158] r3 : e7fddef0  r2 : ee8ab440  r1 : c1025ab0  r0 : 40004000
[   68.403165] Flags: nzCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM
Segment none
[   68.403171] Control: 10c5387d  Table: 4000404a  DAC: 00000051
[   68.403177] Process swapper/1 (pid: 0, stack limit = 0xddfe9e0d)
[   68.403183] Stack: (0xee925fe8 to 0xee926000)
[   68.403192] 5fe0:                   00000001 c1007470 c10074b4
c01109a0 00000000 00000000
[   68.403203] [<c0110a68>] (secondary_start_kernel) from [<c01109a0>]
(arch_cpu_idle_dead+0x54/0x84)
[   68.403213] Code: 00004000 04000000 00000000 00000000 (00000001)
[   68.403221] ---[ end trace be591873dbd10700 ]---
[   68.403228] Kernel panic - not syncing: Attempted to kill the idle task!

The c0110a68 from secondary_start_kernel pointed to local_flush_bp_all
arch/arm/include/asm/tlbflush.h:550

I need definitely more time for narrowing this down. It might be that
some other changes are affecting this as well.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply
* Re: [shawnguo:imx/soc 2/2] arch/arm/Kconfig.debug:1445: syntax error
From: Shawn Guo @ 2018-12-06 13:57 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: kernel, kbuild test robot, linux-arm-kernel, kbuild-all
In-Reply-To: <20181206130617.c3x353tgwyxjszc4@pengutronix.de>

On Thu, Dec 06, 2018 at 02:06:17PM +0100, Uwe Kleine-König wrote:
> Hello,
> 
> On Thu, Dec 06, 2018 at 08:44:30PM +0800, kbuild test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git imx/soc
> > head:   911dccedb00e5b45cf2d0fafc21aba233b58e115
> > commit: 911dccedb00e5b45cf2d0fafc21aba233b58e115 [2/2] ARM: debug-imx: only define DEBUG_IMX_UART_PORT if needed
> > config: arm-hackkit_defconfig
> > compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
> > reproduce:
> >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >         chmod +x ~/bin/make.cross
> >         git checkout 911dccedb00e5b45cf2d0fafc21aba233b58e115
> >         GCC_VERSION=7.2.0 make.cross ARCH=arm  hackkit_defconfig
> >         GCC_VERSION=7.2.0 make.cross ARCH=arm 
> > 
> > All errors (new ones prefixed by >>):
> > 
> > >> arch/arm/Kconfig.debug:1445: syntax error
> > >> arch/arm/Kconfig.debug:1444: invalid option
> 
> hmm, I was sure I tested that, but I can confirm it fails for me, too.
> 
> The obvious fix is:
> 
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 3f057593db01..c253a4e79868 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -1441,18 +1441,18 @@ config DEBUG_OMAP2PLUS_UART
>  
>  config DEBUG_IMX_UART_PORT
>  	int "i.MX Debug UART Port Selection"
> -	depends on DEBUG_IMX1_UART ||
> -		   DEBUG_IMX25_UART ||
> -		   DEBUG_IMX21_IMX27_UART ||
> -		   DEBUG_IMX31_UART ||
> -		   DEBUG_IMX35_UART ||
> -		   DEBUG_IMX50_UART ||
> -		   DEBUG_IMX51_UART ||
> -		   DEBUG_IMX53_UART ||
> -		   DEBUG_IMX6Q_UART ||
> -		   DEBUG_IMX6SL_UART ||
> -		   DEBUG_IMX6SX_UART ||
> -		   DEBUG_IMX6UL_UART ||
> +	depends on DEBUG_IMX1_UART || \
> +		   DEBUG_IMX25_UART || \
> +		   DEBUG_IMX21_IMX27_UART || \
> +		   DEBUG_IMX31_UART || \
> +		   DEBUG_IMX35_UART || \
> +		   DEBUG_IMX50_UART || \
> +		   DEBUG_IMX51_UART || \
> +		   DEBUG_IMX53_UART || \
> +		   DEBUG_IMX6Q_UART || \
> +		   DEBUG_IMX6SL_UART || \
> +		   DEBUG_IMX6SX_UART || \
> +		   DEBUG_IMX6UL_UART || \
>  		   DEBUG_IMX7D_UART
>  	default 1
>  	help
> 
> @Shawn: Can you squash this into the original commit?

Done.

Shawn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply
* Re: Moving ARM dts files
From: Rob Herring @ 2018-12-06 13:58 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: Andrew Lunn, Alexandre Belloni, Tony Lindgren, Linus Walleij,
	Liviu Dudau, Masahiro Yamada, Thierry Reding, Florian Fainelli,
	Kevin Hilman, Gregory CLEMENT, Michal Simek, Krzysztof Kozlowski,
	ARM-SoC Maintainers, Joel Stanley, Andy Gross, devicetree,
	Jason Cooper, Simon Horman,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	Jisheng Zhang, Maxime Coquelin, Shawn Guo, Andreas Färber,
	Daniel Mack
In-Reply-To: <20181206133922.4y4qnrqcjtog3ukt@pengutronix.de>

On Thu, Dec 6, 2018 at 7:39 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> Hello,
>
> On Wed, Dec 05, 2018 at 09:01:59AM -0600, Rob Herring wrote:
> > i.MX23 is a Sigmatel chip STMP??
>
> I think the Freescale i.MX23 didn't exist at Sigmatel back then. AFAIK
> this is a new design using IP from Sigmatel after the aquisition.

It is not. I was in the i.MX group which Sigmatel was merged into at
the time. Purely marketing rebranding.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply
* [PATCH 0/2] pinctrl: sunxi: Account for per-bank GPIO regulators
From: Maxime Ripard @ 2018-12-06 14:02 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard, Linus Walleij
  Cc: linux-gpio, Mylene Josserand, linux-arm-kernel, Thomas Petazzoni

Hi,

Here is a first attempt at getting the regulators properly accounted for
the GPIO banks on the Allwinner SoCs.

The main interogation I have currently is whether we should always try to
get the regulator for the current branch, or if we should restrict it to
the one available on the SoCs.

Let me know what you think,
Maxime

Maxime Ripard (2):
  pinctrl: sunxi: Deal with per-bank regulators
  ARM: dts: sun7i: bananapi: Add GPIO banks regulators

 arch/arm/boot/dts/sun7i-a20-bananapi.dts |  5 ++-
 drivers/pinctrl/sunxi/pinctrl-sunxi.c    | 63 +++++++++++++++++++++++++-
 drivers/pinctrl/sunxi/pinctrl-sunxi.h    |  6 ++-
 3 files changed, 74 insertions(+)

base-commit: 651022382c7f8da46cb4872a545ee1da6d097d2a
-- 
git-series 0.9.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply
* [PATCH 2/2] ARM: dts: sun7i: bananapi: Add GPIO banks regulators
From: Maxime Ripard @ 2018-12-06 14:02 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard, Linus Walleij
  Cc: linux-gpio, Mylene Josserand, linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <cover.50931fbda5c95345087740e4c1ef5a57fdd53480.1544104801.git-series.maxime.ripard@bootlin.com>

The bananapi has all its bank regulators tied to the 3v3 static regulator.
Make sure it's properly represented.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 arch/arm/boot/dts/sun7i-a20-bananapi.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 70dfc4ac0bb5..cd8157c125eb 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -201,6 +201,11 @@
 };
 
 &pio {
+	vcc-pa-supply = <&reg_vcc3v3>;
+	vcc-pc-supply = <&reg_vcc3v3>;
+	vcc-pe-supply = <&reg_vcc3v3>;
+	vcc-pf-supply = <&reg_vcc3v3>;
+	vcc-pg-supply = <&reg_vcc3v3>;
 	gpio-line-names =
 		/* PA */
 		"ERXD3", "ERXD2", "ERXD1", "ERXD0", "ETXD3",
-- 
git-series 0.9.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related
* [PATCH 1/2] pinctrl: sunxi: Deal with per-bank regulators
From: Maxime Ripard @ 2018-12-06 14:02 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard, Linus Walleij
  Cc: linux-gpio, Mylene Josserand, linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <cover.50931fbda5c95345087740e4c1ef5a57fdd53480.1544104801.git-series.maxime.ripard@bootlin.com>

The Allwinner SoCs have on most of their GPIO banks a regulator input.

This issue was mainly ignored so far because either the regulator was a
static regulator that would be providing power anyway, or the bank was used
for a feature unsupported so far (CSI). For the odd cases, enabling it in
the bootloader was the preferred option.

However, now that we are starting to support those features, and that we
can't really rely on the bootloader for this, we need to model those
regulators as such in the DT.

This is slightly more complicated than what it looks like, since some
regulators will be tied to the PMIC, and in order to have access to the
PMIC bus, you need to mux its pins, which will need the pinctrl driver,
that needs the regulator driver to be registered. And this is how you get a
circular dependency.

In practice however, the hardware cannot fall into this case since it would
result in a completely unusable bus. In order to avoid that circular
dependency, we can thus get and enable the regulators at pin_request time.
We'll then need to account for the references of all the pins of a
particular branch to know when to put the reference, but it works pretty
nicely once implemented.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 drivers/pinctrl/sunxi/pinctrl-sunxi.c | 63 ++++++++++++++++++++++++++++-
 drivers/pinctrl/sunxi/pinctrl-sunxi.h |  6 +++-
 2 files changed, 69 insertions(+)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 34e17376ef99..5d9184d18c16 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -26,6 +26,7 @@
 #include <linux/pinctrl/pinctrl.h>
 #include <linux/pinctrl/pinconf-generic.h>
 #include <linux/pinctrl/pinmux.h>
+#include <linux/regulator/consumer.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 
@@ -693,12 +694,74 @@ sunxi_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
 	return 0;
 }
 
+static int sunxi_pmx_request(struct pinctrl_dev *pctldev, unsigned offset)
+{
+	struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
+	unsigned short bank = offset / PINS_PER_BANK;
+	struct sunxi_pinctrl_regulator *s_reg = &pctl->regulators[bank];
+	struct regulator *reg;
+	int ret;
+
+	reg = s_reg->regulator;
+	if (!reg) {
+		char supply[16];
+
+		snprintf(supply, sizeof(supply), "vcc-p%c", 'a' + bank);
+		reg = regulator_get(pctl->dev, supply);
+		if (IS_ERR(reg)) {
+			dev_err(pctl->dev, "Couldn't get bank P%c regulator\n",
+				'A' + bank);
+			return PTR_ERR(reg);
+		}
+
+		s_reg->regulator = reg;
+		refcount_set(&s_reg->refcount, 1);
+	} else {
+		refcount_inc(&s_reg->refcount);
+	}
+
+	ret = regulator_enable(reg);
+	if (ret) {
+		dev_err(pctl->dev,
+			"Couldn't enable bank P%c regulator\n", 'A' + bank);
+		goto out;
+	}
+
+	return 0;
+
+out:
+	if (refcount_dec_and_test(&s_reg->refcount)) {
+		regulator_put(s_reg->regulator);
+		s_reg->regulator = NULL;
+	}
+
+	return ret;
+}
+
+static int sunxi_pmx_free(struct pinctrl_dev *pctldev, unsigned offset)
+{
+	struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
+	unsigned short bank = offset / PINS_PER_BANK;
+	struct sunxi_pinctrl_regulator *s_reg = &pctl->regulators[bank];
+
+	if (!refcount_dec_and_test(&s_reg->refcount))
+		return 0;
+
+	regulator_disable(s_reg->regulator);
+	regulator_put(s_reg->regulator);
+	s_reg->regulator = NULL;
+
+	return 0;
+}
+
 static const struct pinmux_ops sunxi_pmx_ops = {
 	.get_functions_count	= sunxi_pmx_get_funcs_cnt,
 	.get_function_name	= sunxi_pmx_get_func_name,
 	.get_function_groups	= sunxi_pmx_get_func_groups,
 	.set_mux		= sunxi_pmx_set_mux,
 	.gpio_set_direction	= sunxi_pmx_gpio_set_direction,
+	.request		= sunxi_pmx_request,
+	.free			= sunxi_pmx_free,
 	.strict			= true,
 };
 
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
index 4a892e7dde66..e340d2a24b44 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
@@ -126,11 +126,17 @@ struct sunxi_pinctrl_group {
 	unsigned	pin;
 };
 
+struct sunxi_pinctrl_regulator {
+	struct regulator	*regulator;
+	refcount_t		refcount;
+};
+
 struct sunxi_pinctrl {
 	void __iomem			*membase;
 	struct gpio_chip		*chip;
 	const struct sunxi_pinctrl_desc	*desc;
 	struct device			*dev;
+	struct sunxi_pinctrl_regulator	regulators[12];
 	struct irq_domain		*domain;
 	struct sunxi_pinctrl_function	*functions;
 	unsigned			nfunctions;
-- 
git-series 0.9.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related
* Re: Moving ARM dts files
From: Alexandre Belloni @ 2018-12-06 14:05 UTC (permalink / raw)
  To: Rob Herring
  Cc: Andrew Lunn, Tony Lindgren, Linus Walleij, Liviu Dudau,
	Masahiro Yamada, Thierry Reding, Florian Fainelli, Kevin Hilman,
	Gregory CLEMENT, Michal Simek, Krzysztof Kozlowski,
	ARM-SoC Maintainers, Joel Stanley, Uwe Kleine-König,
	Andy Gross, devicetree, Jason Cooper, Simon Horman,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	Jisheng Zhang, Maxime Coquelin, Shawn Guo, Andreas Färber,
	Daniel Mack
In-Reply-To: <CAL_Jsq+PB3Pmg1RmNqj0whapbcqRBXDNWi4LpjPqqCKeLHbR=A@mail.gmail.com>

On 06/12/2018 07:58:24-0600, Rob Herring wrote:
> On Thu, Dec 6, 2018 at 7:39 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> >
> > Hello,
> >
> > On Wed, Dec 05, 2018 at 09:01:59AM -0600, Rob Herring wrote:
> > > i.MX23 is a Sigmatel chip STMP??
> >
> > I think the Freescale i.MX23 didn't exist at Sigmatel back then. AFAIK
> > this is a new design using IP from Sigmatel after the aquisition.
> 
> It is not. I was in the i.MX group which Sigmatel was merged into at
> the time. Purely marketing rebranding.
> 

Wouldn't it be easier to name the directory to the corresponding mach-*
entry?

So, imx23 and imx28 would go to mxs/, other imx in imx/. And this also
solves the Marvell mess with the Synaptics Socs going in berlin/ and the
other ones in mvebu/.


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox