* [PATCH V3 0/6] ARM64: Uprobe support added
From: Catalin Marinas @ 2016-11-04 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1478068479.git.panand@redhat.com>
On Wed, Nov 02, 2016 at 02:40:40PM +0530, Pratyush Anand wrote:
> Pratyush Anand (6):
> arm64: kprobe: protect/rename few definitions to be reused by uprobe
> arm64: kgdb_step_brk_fn: ignore other's exception
> arm64: Handle TRAP_TRACE for user mode as well
> arm64: Handle TRAP_BRKPT for user mode as well
> arm64: introduce mm context flag to keep 32 bit task information
> arm64: Add uprobe support
I queued the patches for 4.10. I will push them into -next sometime next
week once I do some testing (I'm currently at the LPC).
Thanks.
--
Catalin
^ permalink raw reply
* [RFC PATCH v2 8/8] arm64: Wire up and expose the new compat vDSO
From: Kevin Brodsky @ 2016-11-04 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104164743.c35wxhgzs6uigv6j@localhost>
On 04/11/2016 10:47, Catalin Marinas wrote:
> On Fri, Nov 04, 2016 at 10:30:08AM -0600, Kevin Brodsky wrote:
>> On 04/11/2016 09:50, Catalin Marinas wrote:
>>> On Thu, Oct 27, 2016 at 05:30:58PM +0100, Kevin Brodsky wrote:
>>>> * The vDSO page replaces the vector page. The vDSO provides its own
>>>> sigreturn trampolines, replacing those in the vector page, but the
>>>> kuser helpers are gone. As a result enabling the compat vDSO will
>>>> break userspace programs relying on the kuser helpers.
>>> I think vDSO and vectors page should not exclude each other. If you want
>>> to disable the vectors page, let's make it an independent config option
>>> like the KUSER_HELPERS in arch/arm64/mm/Kconfig. But I would very much
>>> like to be able to have both the vDSO and the vectors page at the same
>>> time.
>> Indeed, I've had exactly the same feedback from Google yesterday (apparently
>> many Android apps with native libs still target ARMv6....). I'll add the
>> option to keep the kuser helpers.
>>
>> There's a small problem though: how to ensure that the kuser helpers +
>> sigreturn trampolines are always included if the compat vDSO is not built? I
>> can enforce CONFIG_KUSER_HELPERS if !CONFIG_VDSO32 (directly in the
>> code/Makefiles), but the dependency cannot be expressed in Kconfig.
> Or you could insert a separate "sigpage" as arm32 does. This could leave
> independently of vDSO or vectors page.
Yeah I thought about this too. It's a bit more work but probably cleaner and more
flexible, that would also allow to disable the kuser helpers independently of the
compat vDSO.
Thanks,
Kevin
^ permalink raw reply
* [PATCH] arm64: percpu: kill off final ACCESS_ONCE() uses
From: Mark Rutland @ 2016-11-04 18:17 UTC (permalink / raw)
To: linux-arm-kernel
For several reasons it is preferable to use {READ,WRITE}_ONCE() rather than
ACCESS_ONCE(). For example, these handle aggregate types, result in shorter
source code, and better document the intended access (which may be useful for
instrumentation features such as the upcoming KTSAN).
Over a number of patches, most uses of ACCESS_ONCE() in arch/arm64 have been
migrated to {READ,WRITE}_ONCE(). For consistency, and the above reasons, this
patch migrates the final remaining uses.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/percpu.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/percpu.h b/arch/arm64/include/asm/percpu.h
index 5394c84..4afb6fc 100644
--- a/arch/arm64/include/asm/percpu.h
+++ b/arch/arm64/include/asm/percpu.h
@@ -101,16 +101,16 @@ static inline unsigned long __percpu_read(void *ptr, int size)
switch (size) {
case 1:
- ret = ACCESS_ONCE(*(u8 *)ptr);
+ ret = READ_ONCE(*(u8 *)ptr);
break;
case 2:
- ret = ACCESS_ONCE(*(u16 *)ptr);
+ ret = READ_ONCE(*(u16 *)ptr);
break;
case 4:
- ret = ACCESS_ONCE(*(u32 *)ptr);
+ ret = READ_ONCE(*(u32 *)ptr);
break;
case 8:
- ret = ACCESS_ONCE(*(u64 *)ptr);
+ ret = READ_ONCE(*(u64 *)ptr);
break;
default:
BUILD_BUG();
@@ -123,16 +123,16 @@ static inline void __percpu_write(void *ptr, unsigned long val, int size)
{
switch (size) {
case 1:
- ACCESS_ONCE(*(u8 *)ptr) = (u8)val;
+ WRITE_ONCE(*(u8 *)ptr, (u8)val);
break;
case 2:
- ACCESS_ONCE(*(u16 *)ptr) = (u16)val;
+ WRITE_ONCE(*(u16 *)ptr, (u16)val);
break;
case 4:
- ACCESS_ONCE(*(u32 *)ptr) = (u32)val;
+ WRITE_ONCE(*(u32 *)ptr, (u32)val);
break;
case 8:
- ACCESS_ONCE(*(u64 *)ptr) = (u64)val;
+ WRITE_ONCE(*(u64 *)ptr, (u64)val);
break;
default:
BUILD_BUG();
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/6] arm64: arch_timer: Introduce a generic erratum handing mechanism for fsl-a008585
From: Scott Wood @ 2016-11-04 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478264794-14652-2-git-send-email-dingtianhong@huawei.com>
On Fri, Nov 04, 2016 at 09:06:30PM +0800, Ding Tianhong wrote:
> The workaround for hisilicon,161601 will check the return value of the system counter
> by different way, in order to distinguish with the fsl-a008585 workaround, introduce
> a new generic erratum handing mechanism for fsl-a008585 and rename some functions.
>
> v2: Introducing a new generic erratum handling mechanism for fsl erratum a008585.
>
> v3: Introducing the erratum_workaround_set_sne generic function for fsl erratum a008585
> and make the #define __fsl_a008585_read_reg to be private to the .c file instead of
> being globally visible. After discussion with Marc and Will, a consensus decision was
> made to remove the commandline parameter for enabling fsl,erratum-a008585 erratum,
> and make some generic name more specific, export timer_unstable_counter_workaround
> for module access.
The command line paramter was added at Marc's request to provide a way of
enbaling the workaround in a KVM guest, until API is added to allow QEMU to
discover the need to set the property in the guest device tree. Is there an
alternative?
-Scott
^ permalink raw reply
* [PULL 0/3] KVM/ARM updates for v4.9-rc4
From: Marc Zyngier @ 2016-11-04 18:36 UTC (permalink / raw)
To: linux-arm-kernel
Paolo, Radim,
Please find below the KVM/ARM updates for v4.9-rc4 (or later if we've
already missed the boat).
Thanks,
M.
The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:
Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)
are available in the git repository at:
git://git.kernel.org:/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvm-arm-for-v4.9-rc4
for you to fetch changes up to d42c79701a3ee5c38fbbc82f98a140420bd40134:
KVM: arm/arm64: vgic: Kick VCPUs when queueing already pending IRQs (2016-11-04 17:56:56 +0000)
----------------------------------------------------------------
KVM/ARM updates for v4.9-rc4
- Kick the vcpu when a pending interrupt becomes pending again
- Prevent access to invalid interrupt registers
- Invalid TLBs when two vcpus from the same VM share a CPU
----------------------------------------------------------------
Andre Przywara (1):
KVM: arm/arm64: vgic: Prevent access to invalid SPIs
Marc Zyngier (1):
arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
Shih-Wei Li (1):
KVM: arm/arm64: vgic: Kick VCPUs when queueing already pending IRQs
arch/arm/include/asm/kvm_asm.h | 1 +
arch/arm/include/asm/kvm_host.h | 3 +++
arch/arm/include/asm/kvm_hyp.h | 1 +
arch/arm/kvm/arm.c | 27 +++++++++++++++++++++++++-
arch/arm/kvm/hyp/tlb.c | 15 ++++++++++++++
arch/arm64/include/asm/kvm_asm.h | 1 +
arch/arm64/include/asm/kvm_host.h | 3 +++
arch/arm64/include/asm/kvm_mmu.h | 2 +-
arch/arm64/kvm/hyp/tlb.c | 15 ++++++++++++++
virt/kvm/arm/vgic/vgic-mmio.c | 41 ++++++++++++++++++++++++++-------------
virt/kvm/arm/vgic/vgic-mmio.h | 14 ++++++-------
virt/kvm/arm/vgic/vgic.c | 12 ++++++++++++
12 files changed, 112 insertions(+), 23 deletions(-)
^ permalink raw reply
* [PATCH 1/3] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
From: Marc Zyngier @ 2016-11-04 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104183638.28137-1-marc.zyngier@arm.com>
Architecturally, TLBs are private to the (physical) CPU they're
associated with. But when multiple vcpus from the same VM are
being multiplexed on the same CPU, the TLBs are not private
to the vcpus (and are actually shared across the VMID).
Let's consider the following scenario:
- vcpu-0 maps PA to VA
- vcpu-1 maps PA' to VA
If run on the same physical CPU, vcpu-1 can hit TLB entries generated
by vcpu-0 accesses, and access the wrong physical page.
The solution to this is to keep a per-VM map of which vcpu ran last
on each given physical CPU, and invalidate local TLBs when switching
to a different vcpu from the same VM.
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm/include/asm/kvm_asm.h | 1 +
arch/arm/include/asm/kvm_host.h | 3 +++
arch/arm/include/asm/kvm_hyp.h | 1 +
arch/arm/kvm/arm.c | 27 ++++++++++++++++++++++++++-
arch/arm/kvm/hyp/tlb.c | 15 +++++++++++++++
arch/arm64/include/asm/kvm_asm.h | 1 +
arch/arm64/include/asm/kvm_host.h | 3 +++
arch/arm64/include/asm/kvm_mmu.h | 2 +-
arch/arm64/kvm/hyp/tlb.c | 15 +++++++++++++++
9 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index d7ea6bcb29bf..8ef05381984b 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -66,6 +66,7 @@ extern char __kvm_hyp_vector[];
extern void __kvm_flush_vm_context(void);
extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
+extern void __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu);
extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 2d19e02d03fd..d5423ab15ed5 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -57,6 +57,9 @@ struct kvm_arch {
/* VTTBR value associated with below pgd and vmid */
u64 vttbr;
+ /* The last vcpu id that ran on each physical CPU */
+ int __percpu *last_vcpu_ran;
+
/* Timer */
struct arch_timer_kvm timer;
diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
index 343135ede5fa..58508900c4bb 100644
--- a/arch/arm/include/asm/kvm_hyp.h
+++ b/arch/arm/include/asm/kvm_hyp.h
@@ -71,6 +71,7 @@
#define ICIALLUIS __ACCESS_CP15(c7, 0, c1, 0)
#define ATS1CPR __ACCESS_CP15(c7, 0, c8, 0)
#define TLBIALLIS __ACCESS_CP15(c8, 0, c3, 0)
+#define TLBIALL __ACCESS_CP15(c8, 0, c7, 0)
#define TLBIALLNSNHIS __ACCESS_CP15(c8, 4, c3, 4)
#define PRRR __ACCESS_CP15(c10, 0, c2, 0)
#define NMRR __ACCESS_CP15(c10, 0, c2, 1)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 08bb84f2ad58..19b5f5c1c0ff 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -114,11 +114,18 @@ void kvm_arch_check_processor_compat(void *rtn)
*/
int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
{
- int ret = 0;
+ int ret, cpu;
if (type)
return -EINVAL;
+ kvm->arch.last_vcpu_ran = alloc_percpu(typeof(*kvm->arch.last_vcpu_ran));
+ if (!kvm->arch.last_vcpu_ran)
+ return -ENOMEM;
+
+ for_each_possible_cpu(cpu)
+ *per_cpu_ptr(kvm->arch.last_vcpu_ran, cpu) = -1;
+
ret = kvm_alloc_stage2_pgd(kvm);
if (ret)
goto out_fail_alloc;
@@ -141,6 +148,8 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
out_free_stage2_pgd:
kvm_free_stage2_pgd(kvm);
out_fail_alloc:
+ free_percpu(kvm->arch.last_vcpu_ran);
+ kvm->arch.last_vcpu_ran = NULL;
return ret;
}
@@ -168,6 +177,9 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
{
int i;
+ free_percpu(kvm->arch.last_vcpu_ran);
+ kvm->arch.last_vcpu_ran = NULL;
+
for (i = 0; i < KVM_MAX_VCPUS; ++i) {
if (kvm->vcpus[i]) {
kvm_arch_vcpu_free(kvm->vcpus[i]);
@@ -312,6 +324,19 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
{
+ int *last_ran;
+
+ last_ran = this_cpu_ptr(vcpu->kvm->arch.last_vcpu_ran);
+
+ /*
+ * We might get preempted before the vCPU actually runs, but
+ * over-invalidation doesn't affect correctness.
+ */
+ if (*last_ran != vcpu->vcpu_id) {
+ kvm_call_hyp(__kvm_tlb_flush_local_vmid, vcpu);
+ *last_ran = vcpu->vcpu_id;
+ }
+
vcpu->cpu = cpu;
vcpu->arch.host_cpu_context = this_cpu_ptr(kvm_host_cpu_state);
diff --git a/arch/arm/kvm/hyp/tlb.c b/arch/arm/kvm/hyp/tlb.c
index 729652854f90..6d810af2d9fd 100644
--- a/arch/arm/kvm/hyp/tlb.c
+++ b/arch/arm/kvm/hyp/tlb.c
@@ -55,6 +55,21 @@ void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
__kvm_tlb_flush_vmid(kvm);
}
+void __hyp_text __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu)
+{
+ struct kvm *kvm = kern_hyp_va(kern_hyp_va(vcpu)->kvm);
+
+ /* Switch to requested VMID */
+ write_sysreg(kvm->arch.vttbr, VTTBR);
+ isb();
+
+ write_sysreg(0, TLBIALL);
+ dsb(nsh);
+ isb();
+
+ write_sysreg(0, VTTBR);
+}
+
void __hyp_text __kvm_flush_vm_context(void)
{
write_sysreg(0, TLBIALLNSNHIS);
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 18f746551bf6..ec3553eb9349 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -54,6 +54,7 @@ extern char __kvm_hyp_vector[];
extern void __kvm_flush_vm_context(void);
extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
+extern void __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu);
extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index bd94e6766759..e5050388e062 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -62,6 +62,9 @@ struct kvm_arch {
/* VTTBR value associated with above pgd and vmid */
u64 vttbr;
+ /* The last vcpu id that ran on each physical CPU */
+ int __percpu *last_vcpu_ran;
+
/* The maximum number of vCPUs depends on the used GIC model */
int max_vcpus;
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index a79b969c26fc..6f72fe8b0e3e 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -128,7 +128,7 @@ static inline unsigned long __kern_hyp_va(unsigned long v)
return v;
}
-#define kern_hyp_va(v) (typeof(v))(__kern_hyp_va((unsigned long)(v)))
+#define kern_hyp_va(v) ((typeof(v))(__kern_hyp_va((unsigned long)(v))))
/*
* We currently only support a 40bit IPA.
diff --git a/arch/arm64/kvm/hyp/tlb.c b/arch/arm64/kvm/hyp/tlb.c
index 9cc0ea784ae6..88e2f2b938f0 100644
--- a/arch/arm64/kvm/hyp/tlb.c
+++ b/arch/arm64/kvm/hyp/tlb.c
@@ -64,6 +64,21 @@ void __hyp_text __kvm_tlb_flush_vmid(struct kvm *kvm)
write_sysreg(0, vttbr_el2);
}
+void __hyp_text __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu)
+{
+ struct kvm *kvm = kern_hyp_va(kern_hyp_va(vcpu)->kvm);
+
+ /* Switch to requested VMID */
+ write_sysreg(kvm->arch.vttbr, vttbr_el2);
+ isb();
+
+ asm volatile("tlbi vmalle1" : : );
+ dsb(nsh);
+ isb();
+
+ write_sysreg(0, vttbr_el2);
+}
+
void __hyp_text __kvm_flush_vm_context(void)
{
dsb(ishst);
--
2.10.1
^ permalink raw reply related
* [PATCH 2/3] KVM: arm/arm64: vgic: Prevent access to invalid SPIs
From: Marc Zyngier @ 2016-11-04 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104183638.28137-1-marc.zyngier@arm.com>
From: Andre Przywara <andre.przywara@arm.com>
In our VGIC implementation we limit the number of SPIs to a number
that the userland application told us. Accordingly we limit the
allocation of memory for virtual IRQs to that number.
However in our MMIO dispatcher we didn't check if we ever access an
IRQ beyond that limit, leading to out-of-bound accesses.
Add a test against the number of allocated SPIs in check_region().
Adjust the VGIC_ADDR_TO_INT macro to avoid an actual division, which
is not implemented on ARM(32).
[maz: cleaned-up original patch]
Cc: stable at vger.kernel.org
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/vgic/vgic-mmio.c | 41 +++++++++++++++++++++++++++--------------
virt/kvm/arm/vgic/vgic-mmio.h | 14 +++++++-------
2 files changed, 34 insertions(+), 21 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
index e18b30ddcdce..ebe1b9fa3c4d 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.c
+++ b/virt/kvm/arm/vgic/vgic-mmio.c
@@ -453,17 +453,33 @@ struct vgic_io_device *kvm_to_vgic_iodev(const struct kvm_io_device *dev)
return container_of(dev, struct vgic_io_device, dev);
}
-static bool check_region(const struct vgic_register_region *region,
+static bool check_region(const struct kvm *kvm,
+ const struct vgic_register_region *region,
gpa_t addr, int len)
{
- if ((region->access_flags & VGIC_ACCESS_8bit) && len == 1)
- return true;
- if ((region->access_flags & VGIC_ACCESS_32bit) &&
- len == sizeof(u32) && !(addr & 3))
- return true;
- if ((region->access_flags & VGIC_ACCESS_64bit) &&
- len == sizeof(u64) && !(addr & 7))
- return true;
+ int flags, nr_irqs = kvm->arch.vgic.nr_spis + VGIC_NR_PRIVATE_IRQS;
+
+ switch (len) {
+ case sizeof(u8):
+ flags = VGIC_ACCESS_8bit;
+ break;
+ case sizeof(u32):
+ flags = VGIC_ACCESS_32bit;
+ break;
+ case sizeof(u64):
+ flags = VGIC_ACCESS_64bit;
+ break;
+ default:
+ return false;
+ }
+
+ if ((region->access_flags & flags) && IS_ALIGNED(addr, len)) {
+ if (!region->bits_per_irq)
+ return true;
+
+ /* Do we access a non-allocated IRQ? */
+ return VGIC_ADDR_TO_INTID(addr, region->bits_per_irq) < nr_irqs;
+ }
return false;
}
@@ -477,7 +493,7 @@ static int dispatch_mmio_read(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
region = vgic_find_mmio_region(iodev->regions, iodev->nr_regions,
addr - iodev->base_addr);
- if (!region || !check_region(region, addr, len)) {
+ if (!region || !check_region(vcpu->kvm, region, addr, len)) {
memset(val, 0, len);
return 0;
}
@@ -510,10 +526,7 @@ static int dispatch_mmio_write(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
region = vgic_find_mmio_region(iodev->regions, iodev->nr_regions,
addr - iodev->base_addr);
- if (!region)
- return 0;
-
- if (!check_region(region, addr, len))
+ if (!region || !check_region(vcpu->kvm, region, addr, len))
return 0;
switch (iodev->iodev_type) {
diff --git a/virt/kvm/arm/vgic/vgic-mmio.h b/virt/kvm/arm/vgic/vgic-mmio.h
index 4c34d39d44a0..84961b4e4422 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.h
+++ b/virt/kvm/arm/vgic/vgic-mmio.h
@@ -50,15 +50,15 @@ extern struct kvm_io_device_ops kvm_io_gic_ops;
#define VGIC_ADDR_IRQ_MASK(bits) (((bits) * 1024 / 8) - 1)
/*
- * (addr & mask) gives us the byte offset for the INT ID, so we want to
- * divide this with 'bytes per irq' to get the INT ID, which is given
- * by '(bits) / 8'. But we do this with fixed-point-arithmetic and
- * take advantage of the fact that division by a fraction equals
- * multiplication with the inverted fraction, and scale up both the
- * numerator and denominator with 8 to support at most 64 bits per IRQ:
+ * (addr & mask) gives us the _byte_ offset for the INT ID.
+ * We multiply this by 8 the get the _bit_ offset, then divide this by
+ * the number of bits to learn the actual INT ID.
+ * But instead of a division (which requires a "long long div" implementation),
+ * we shift by the binary logarithm of <bits>.
+ * This assumes that <bits> is a power of two.
*/
#define VGIC_ADDR_TO_INTID(addr, bits) (((addr) & VGIC_ADDR_IRQ_MASK(bits)) * \
- 64 / (bits) / 8)
+ 8 >> ilog2(bits))
/*
* Some VGIC registers store per-IRQ information, with a different number
--
2.10.1
^ permalink raw reply related
* [PATCH 3/3] KVM: arm/arm64: vgic: Kick VCPUs when queueing already pending IRQs
From: Marc Zyngier @ 2016-11-04 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104183638.28137-1-marc.zyngier@arm.com>
From: Shih-Wei Li <shihwei@cs.columbia.edu>
In cases like IPI, we could be queueing an interrupt for a VCPU
that is already running and is not about to exit, because the
VCPU has entered the VM with the interrupt pending and would
not trap on EOI'ing that interrupt. This could result to delays
in interrupt deliveries or even loss of interrupts.
To guarantee prompt interrupt injection, here we have to try to
kick the VCPU.
Signed-off-by: Shih-Wei Li <shihwei@cs.columbia.edu>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/vgic/vgic.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
index 2893d5ba523a..6440b56ec90e 100644
--- a/virt/kvm/arm/vgic/vgic.c
+++ b/virt/kvm/arm/vgic/vgic.c
@@ -273,6 +273,18 @@ bool vgic_queue_irq_unlock(struct kvm *kvm, struct vgic_irq *irq)
* no more work for us to do.
*/
spin_unlock(&irq->irq_lock);
+
+ /*
+ * We have to kick the VCPU here, because we could be
+ * queueing an edge-triggered interrupt for which we
+ * get no EOI maintenance interrupt. In that case,
+ * while the IRQ is already on the VCPU's AP list, the
+ * VCPU could have EOI'ed the original interrupt and
+ * won't see this one until it exits for some other
+ * reason.
+ */
+ if (vcpu)
+ kvm_vcpu_kick(vcpu);
return false;
}
--
2.10.1
^ permalink raw reply related
* Low network throughput on i.MX28
From: Jörg Krause @ 2016-11-04 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ac897803-47e5-6b0b-5664-6dc165c56c23@i2se.com>
Hi Shawn,
On Wed, 2016-11-02 at 09:24 +0100, Stefan Wahren wrote:
> Am 02.11.2016 um 09:14 schrieb J?rg Krause:
> > On Sat, 2016-10-29 at 11:08 +0200, Stefan Wahren wrote:
> > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 29. Oktober
> > > > 2016
> > > > um 01:07
> > > > geschrieben:
> > > >
> > > >
> > > > You mentioned [1] an optimization in the Freescale vendor Linux
> > > > kernel
> > > > [2]. I would really like to see this optimization in the
> > > > mainline
> > > > kernel.
> > > >
> > > > Did you ever tried to port this code from Freescale to
> > > > mainline?
> > >
> > > Yes, i tried once but i was frustrated soon because of the lot of
> > > required
> > > changes and resulting issues.
> >
> > I got the PIO mode working for the mxs-mmc driver. For this I
> > ported
> > the PIO code from the vendor kernel and removed the usage of the
> > DMA
> > engine entirely.
>
> Good job
>
> >
> > Testing network bandwidth with iperf, I get about ~10Mbit/sec with
> > PIO
> > mode compared to ~6.5Mbit/sec with DMA mode for UDP and about
> > ~6.5Mbit/sec compared to ~4.5Mbit/sec with DMA mode for TCP.
>
> And how about MMC / sd card performance?
I noticed poor performance with the i.MX28 MMC and/or DMA driver using
the mainline kernel compared to the vendor Freescale kernel 2.6.35.
I've seen that hou have added the drivers to mainline some years ago.
My custom i.MX28 board has a wifi chip attached to the SSP2 interface.
Comparing the bandwith with iperf I get >20Mbits/sec on the vendor
kernel and <5Mbits/sec on the mainline kernel.
My best guess is that there is some kind of bottleneck in the drivers.
I already started looking at the vendor drivers as well as@the
mainline drivers, but I need some more investigation to understand the
complexity.
Do you have any idea what the bottleneck might be?
Best regards,
J?rg Krause
^ permalink raw reply
* [PATCH V3 0/6] ARM64: Uprobe support added
From: Catalin Marinas @ 2016-11-04 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104174951.vj4il3xkdy7a2ln7@localhost>
On Fri, Nov 04, 2016 at 11:49:51AM -0600, Catalin Marinas wrote:
> On Wed, Nov 02, 2016 at 02:40:40PM +0530, Pratyush Anand wrote:
> > Pratyush Anand (6):
> > arm64: kprobe: protect/rename few definitions to be reused by uprobe
> > arm64: kgdb_step_brk_fn: ignore other's exception
> > arm64: Handle TRAP_TRACE for user mode as well
> > arm64: Handle TRAP_BRKPT for user mode as well
> > arm64: introduce mm context flag to keep 32 bit task information
> > arm64: Add uprobe support
>
> I queued the patches for 4.10. I will push them into -next sometime next
> week once I do some testing (I'm currently at the LPC).
I spoke too soon. With these patches on top of 4.9-rc3, defconfig
together with FTRACE and UPROBE_EVENT enabled I get:
In file included from /work/Linux/linux-2.6-aarch64/arch/arm64/kernel/probes/decode-insn.c:20:0:
/work/Linux/linux-2.6-aarch64/arch/arm64/include/asm/kprobes.h:52:5: error: conflicting types for 'kprobe_fault_handler'
int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
^~~~~~~~~~~~~~~~~~~~
In file included from /work/Linux/linux-2.6-aarch64/arch/arm64/kernel/probes/decode-insn.c:17:0:
/work/Linux/linux-2.6-aarch64/include/linux/kprobes.h:398:90: note: previous definition of 'kprobe_fault_handler' was here
static inline int kprobe_fault_handler(struct pt_regs *regs, int trapnr)
^
/work/Linux/linux-2.6-aarch64/scripts/Makefile.build:290: recipe for target 'arch/arm64/kernel/probes/decode-insn.o' failed
--
Catalin
^ permalink raw reply
* [PATCH v3 2/6] arm64: arch_timer: Introduce a generic erratum handing mechanism for fsl-a008585
From: Will Deacon @ 2016-11-04 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104182050.GA1651@buserror.net>
On Fri, Nov 04, 2016 at 01:20:50PM -0500, Scott Wood wrote:
> On Fri, Nov 04, 2016 at 09:06:30PM +0800, Ding Tianhong wrote:
> > The workaround for hisilicon,161601 will check the return value of the system counter
> > by different way, in order to distinguish with the fsl-a008585 workaround, introduce
> > a new generic erratum handing mechanism for fsl-a008585 and rename some functions.
> >
> > v2: Introducing a new generic erratum handling mechanism for fsl erratum a008585.
> >
> > v3: Introducing the erratum_workaround_set_sne generic function for fsl erratum a008585
> > and make the #define __fsl_a008585_read_reg to be private to the .c file instead of
> > being globally visible. After discussion with Marc and Will, a consensus decision was
> > made to remove the commandline parameter for enabling fsl,erratum-a008585 erratum,
> > and make some generic name more specific, export timer_unstable_counter_workaround
> > for module access.
>
> The command line paramter was added at Marc's request to provide a way of
> enbaling the workaround in a KVM guest, until API is added to allow QEMU to
> discover the need to set the property in the guest device tree. Is there an
> alternative?
Yes -- generate the device-tree property to indicate that there's an issue.
Will
^ permalink raw reply
* Low network throughput on i.MX28
From: Stefan Wahren @ 2016-11-04 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478285097.26659.2.camel@embedded.rocks>
Hi J?rg,
> J?rg Krause <joerg.krause@embedded.rocks> hat am 4. November 2016 um 19:44
> geschrieben:
>
>
> Hi Shawn,
>
> On Wed, 2016-11-02 at 09:24 +0100, Stefan Wahren wrote:
> > Am 02.11.2016 um 09:14 schrieb J?rg Krause:
> > > On Sat, 2016-10-29 at 11:08 +0200, Stefan Wahren wrote:
> > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 29. Oktober
> > > > > 2016
> > > > > um 01:07
> > > > > geschrieben:
> > > > >
> > > > >
> > > > > You mentioned [1] an optimization in the Freescale vendor Linux
> > > > > kernel
> > > > > [2]. I would really like to see this optimization in the
> > > > > mainline
> > > > > kernel.
> > > > >
> > > > > Did you ever tried to port this code from Freescale to
> > > > > mainline?
> > > >
> > > > Yes, i tried once but i was frustrated soon because of the lot of
> > > > required
> > > > changes and resulting issues.
> > >
> > > I got the PIO mode working for the mxs-mmc driver. For this I
> > > ported
> > > the PIO code from the vendor kernel and removed the usage of the
> > > DMA
> > > engine entirely.
> >
> > Good job
> >
> > >
> > > Testing network bandwidth with iperf, I get about ~10Mbit/sec with
> > > PIO
> > > mode compared to ~6.5Mbit/sec with DMA mode for UDP and about
> > > ~6.5Mbit/sec compared to ~4.5Mbit/sec with DMA mode for TCP.
> >
> > And how about MMC / sd card performance?
>
> I noticed poor performance with the i.MX28 MMC and/or DMA driver using
> the mainline kernel compared to the vendor Freescale kernel 2.6.35.
> I've seen that hou have added the drivers to mainline some years ago.
>
> My custom i.MX28 board has a wifi chip attached to the SSP2 interface.
> Comparing the bandwith with iperf I get >20Mbits/sec on the vendor
> kernel and <5Mbits/sec on the mainline kernel.
there is one thing about the clock handling. I noticed that the Vendor Kernel
round up the clock frequency and the Mainline Kernel round down the clock
frequency [1]. So don't trust the clock ratings from DT / board code. Better
verify the register settings or check it with an osci.
[1] - http://www.spinics.net/lists/linux-mmc/msg09132.html
>
> My best guess is that there is some kind of bottleneck in the drivers.
> I already started looking at the vendor drivers as well as at the
> mainline drivers, but I need some more investigation to understand the
> complexity.
>
> Do you have any idea what the bottleneck might be?
>
> Best regards,
> J?rg Krause
^ permalink raw reply
* [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state
From: Stephen Boyd @ 2016-11-04 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXOW4Ubafu=x9pCw_W-MtLGe3N974dbfHCH5TJuUAeYrQ@mail.gmail.com>
On 11/02, Geert Uytterhoeven wrote:
> On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> >
> > Would the pull requests for clk also have dts changes at the base
> > of the tree? Perhaps clk side can just ack the clk patches and
>
> Yes they would: this is moving functionality from platform code to DT.
> Without the DT updates, it will break bisection (except for R-Car Gen2,
> where we have fallback code to handle old DTBs).
>
> > then have it all routed through arm-soc? The only worry I have is
> > if we need to make some sort of change in clk side that conflicts
> > with these changes. I don't usually like taking dts changes
> > through clk tree, so I'd like to avoid that if possible.
>
> Everything could go through arm-soc only with your Acked-by.
> However, there are new clock drivers pending on this series.
> Either they have to go through arm-soc, too, or this series would
> be pulled into the clk tree with these new clock drivers.
>
> > Part E could happen anytime after everything else happens, so
> > that doesn't seem like a concern.
>
> Part E can indeed by postponed.
> But if parts A-D are applied together, there's no reason to postpone part E.
>
> > Part C could also be made to
> > only call into the new reset drivers if the reset dts nodes are
> > present? If that's done then we could merge clk patches anytime
> > and remove the dead code and the node search at some later time
> > when everything has settled?
>
> That would require adding more backwards compatibility code for
> old DTBs, even for platform where we're not interested in maintaining
> that. In addition, Part C depends on the header file for the reset driver
> to compile the clock driver, even if you would add some DT detection,
> and on the reset driver to link. So I'm afraid this is not feasible.
>
TL;DR: Sounds fine, I'll be on the lookout for the PR.
Longer version: Let me step back a bit and actually think about
this longer than 2 minutes. From what I see
rcar_rst_read_mode_pins() already returns -ENODEV if the nodes
aren't present. Great.
So clk tree could be given a pull for the clk patches, part C, on
top of part A, the reset driver. If the rcar_rst_read_mode_pins()
returns failure because the node is missing, we fall back to the
old style of doing things. Some drivers already do that anyway,
so this looks to be replacing things like
if (rcar_rst_read_mode_pins())
return;
with
if (rcar_rst_read_mode_pins() != -ENODEV)
return;
Then in arm-soc tree, the dts patches are merged. That causes us
to do some duplicate work reading the pins twice in mach-shmobile
and in the new reset driver. That's duplicate/wasteful, but it
works. Finally, everything is merged together into a tagged
release. The mach-shmobile changes can happen anytime after that
(part D). Again we're left with dead code in the clk driver (part
E) until the dependency merges, but that's ok. Once part D merges
we can get rid of the dead code in part E and any backwards
compatibility we don't want to maintain.
In summary, it's all feasible to do this and most people wouldn't
have had to know about the dependency chain but it's not fast by
any means. Instead we merge everything in one shot and get it
over with now.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [RFC PATCH v2 4/8] arm64: compat: Add a 32-bit vDSO
From: Catalin Marinas @ 2016-11-04 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22ae46f6-f881-63ec-388d-8a7f6cf9934d@arm.com>
On Fri, Oct 28, 2016 at 11:20:07AM +0100, Kevin Brodsky wrote:
> On 28/10/16 04:09, Jisheng Zhang wrote:
> > On Thu, 27 Oct 2016 17:30:54 +0100 Kevin Brodsky wrote:
> > > Provide the files necessary for building a compat (AArch32) vDSO in
> > > kernel/vdso32.
> > >
> > > This is mostly an adaptation of the arm vDSO. The most significant
> > > change in vgettimeofday.c is the use of the arm64 vdso_data struct,
> > > allowing the vDSO data page to be shared between the 32 and 64-bit
> > > vDSOs.
> > >
> > > In addition to the time functions, sigreturn trampolines are also
> > > provided, aiming at replacing those in the vector page. To improve
> > > debugging, CFI and unwinding directives are used, based on glibc's
> > > implementation. Symbol offsets are made available to the kernel using
> > > the same method as the 64-bit vDSO.
> > >
> > > There is unfortunately an important caveat to all this: we cannot get
> > > away with hand-coding 32-bit instructions like in kernel/kuser32.S,
> > > this time we really need a 32-bit compiler. The compat vDSO Makefile
> > > relies on CROSS_COMPILE_ARM32 to provide a 32-bit compiler,
> > > appropriate logic will be added to the arm64 Makefile later on to
> > > ensure that an attempt to build the compat vDSO is made only if this
> > > variable has been set properly.
> > >
> > > Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> > > ---
> > > arch/arm64/kernel/vdso32/Makefile | 121 +++++++++++++
> > > arch/arm64/kernel/vdso32/sigreturn.S | 86 +++++++++
> > > arch/arm64/kernel/vdso32/vdso.S | 32 ++++
> > > arch/arm64/kernel/vdso32/vdso.lds.S | 98 +++++++++++
> > > arch/arm64/kernel/vdso32/vgettimeofday.c | 294 +++++++++++++++++++++++++++++++
> > > 5 files changed, 631 insertions(+)
> > > create mode 100644 arch/arm64/kernel/vdso32/Makefile
> > > create mode 100644 arch/arm64/kernel/vdso32/sigreturn.S
> > > create mode 100644 arch/arm64/kernel/vdso32/vdso.S
> > > create mode 100644 arch/arm64/kernel/vdso32/vdso.lds.S
> > > create mode 100644 arch/arm64/kernel/vdso32/vgettimeofday.c
> > >
> > > diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
> > > new file mode 100644
> > > index 000000000000..38facc870f6e
> > > --- /dev/null
> > > +++ b/arch/arm64/kernel/vdso32/Makefile
> > > @@ -0,0 +1,121 @@
> > > +#
> > > +# Building a vDSO image for AArch32.
> > > +#
> > > +# Author: Kevin Brodsky <kevin.brodsky@arm.com>
> > > +# A mix between the arm64 and arm vDSO Makefiles.
> > > +
> > > +CC_ARM32 := $(CROSS_COMPILE_ARM32)gcc
> > > +
> > > +# Same as cc-ldoption, but using CC_ARM32 instead of CC
> > > +cc32-ldoption = $(call try-run,\
> > > + $(CC_ARM32) $(1) -nostdlib -x c /dev/null -o "$$TMP",$(1),$(2))
> > > +
> > > +# Borrow vdsomunge.c from the arm vDSO
> > > +munge := arch/arm/vdso/vdsomunge
> > > +hostprogs-y := $(srctree)/$(munge)
> > > +
> > > +c-obj-vdso := vgettimeofday.o
> > > +asm-obj-vdso := sigreturn.o
> > > +
> > > +# Build rules
> > > +targets := $(c-obj-vdso) $(asm-obj-vdso) vdso.so vdso.so.dbg vdso.so.raw
> > > +c-obj-vdso := $(addprefix $(obj)/, $(c-obj-vdso))
> > > +asm-obj-vdso := $(addprefix $(obj)/, $(asm-obj-vdso))
> > > +obj-vdso := $(c-obj-vdso) $(asm-obj-vdso)
> > > +
> > > +ccflags-y := -fPIC -fno-common -fno-builtin -fno-stack-protector
> > > +ccflags-y += -DDISABLE_BRANCH_PROFILING
> > > +
> > > +# Force -O2 to avoid libgcc dependencies
> > > +VDSO_CFLAGS := -march=armv8-a -O2
> > For completeness, bringing 32bit compiler need to check whether the 32bit
> > toolchain support some options. IIRC, armv8-a support isn't enabled until
> > gcc 4.8, so old toolchains such gcc-4.7 will complain:
> > error: unrecognized argument in option ?-march=armv8-a?
>
> That's a fair point. I guess -march=armv8-a is not strictly necessary and
> the produced vDSO should be fine if arch/arm/vdso also compiles fine.
> However we would still need to pass -march=armv7-a. I'm not sure what to do
> between:
> * Checking that the compiler supports -march=armv8-a when inspecting
> CROSS_COMPILE_ARM32, and if it doesn't vdso32 will not be built.
> * Checking whether -march=armv8-a is available here, and if it is not fall
> back to -march=armv7-a.
Does v8 vs v7 make any difference in the generated code? If not, we
could just stick to armv7-a permanently.
--
Catalin
^ permalink raw reply
* [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Pavel Machek @ 2016-11-04 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104145855.GH21430@atomide.com>
On Fri 2016-11-04 07:58:55, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [161104 00:10]:
> > On Thu 2016-11-03 22:00:56, Matt Ranostay wrote:
> > Do you actually have hardware with more than one bq27xxx?
>
> I can at least see the twl4030 battery/charger features
> being used together with some bq device to monitor the
> battery state. Not sure if that counts as multiple
> instances here though :)
I have that, too, but that was not what i was asking.
Matt wanted support for different polling intervals on different
bq27xxx chips. I'd like to know know if he actually has more than one
bq27xxx in his device...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161104/37ee45ee/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Matt Ranostay @ 2016-11-04 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104202924.GA6841@amd>
On Fri, Nov 4, 2016 at 1:29 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Fri 2016-11-04 07:58:55, Tony Lindgren wrote:
>> * Pavel Machek <pavel@ucw.cz> [161104 00:10]:
>> > On Thu 2016-11-03 22:00:56, Matt Ranostay wrote:
>> > Do you actually have hardware with more than one bq27xxx?
>>
>> I can at least see the twl4030 battery/charger features
>> being used together with some bq device to monitor the
>> battery state. Not sure if that counts as multiple
>> instances here though :)
>
> I have that, too, but that was not what i was asking.
>
> Matt wanted support for different polling intervals on different
> bq27xxx chips. I'd like to know know if he actually has more than one
> bq27xxx in his device...
>
Actually only one bq27xxx chip but in theory we could have more.
> Best regards,
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Applied "ASoC: sun4i-codec: Add support for A31 board level audio routing" to the asoc tree
From: Mark Brown @ 2016-11-04 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103075556.29018-12-wens@csie.org>
The patch
ASoC: sun4i-codec: Add support for A31 board level audio routing
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 300a18d13f7eaec789e79dc45bce026e098b45da Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Thu, 3 Nov 2016 15:55:53 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for A31 board level audio
routing
The A31 SoC's codec has various inputs, outputs and microphone bias
supplies. These can be routed on the board in different ways, such as:
- HPCOM may be connected to have the headphone DC coupled.
- Microphones all use the MBIAS main microphone supply or one mic may
use the HBIAS supply, which supports headset detection and buttons.
- Line Out may be routed to an audio jack, or an onboard speaker amp
with power controls.
Add support for specifying the audio routes in the device tree.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/sound/sun4i-codec.txt | 33 ++++++++++++++++++++++
sound/soc/sunxi/sun4i-codec.c | 21 ++++++++++++--
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
index bf480e9683a3..d91a95377f49 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -22,6 +22,31 @@ Optional properties:
Required properties for the following compatibles:
- "allwinner,sun6i-a31-codec"
- resets: phandle to the reset control for this device
+- allwinner,audio-routing: A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the
+ connection's sink, the second being the connection's
+ source. Valid names include:
+
+ Audio pins on the SoC:
+ "HP"
+ "HPCOM"
+ "LINEIN"
+ "LINEOUT"
+ "MIC1"
+ "MIC2"
+ "MIC3"
+
+ Microphone biases from the SoC:
+ "HBIAS"
+ "MBIAS"
+
+ Board connectors:
+ "Headphone"
+ "Headset Mic"
+ "Line In"
+ "Line Out"
+ "Mic"
+ "Speaker"
Example:
codec: codec at 01c22c00 {
@@ -45,4 +70,12 @@ codec: codec at 01c22c00 {
resets = <&ccu RST_APB1_CODEC>;
dmas = <&dma 15>, <&dma 15>;
dma-names = "rx", "tx";
+ allwinner,audio-routing =
+ "Headphone", "HP",
+ "Speaker", "LINEOUT",
+ "LINEIN", "Line In",
+ "MIC1", "MBIAS",
+ "MIC1", "Mic",
+ "MIC2", "HBIAS",
+ "MIC2", "Headset Mic";
};
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index f55718fe7c5b..1934db29b2b5 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1104,9 +1104,19 @@ static struct snd_soc_card *sun4i_codec_create_card(struct device *dev)
return card;
};
+static const struct snd_soc_dapm_widget sun6i_codec_card_dapm_widgets[] = {
+ SND_SOC_DAPM_HP("Headphone", NULL),
+ SND_SOC_DAPM_LINE("Line In", NULL),
+ SND_SOC_DAPM_LINE("Line Out", NULL),
+ SND_SOC_DAPM_MIC("Headset Mic", NULL),
+ SND_SOC_DAPM_MIC("Mic", NULL),
+ SND_SOC_DAPM_SPK("Speaker", sun4i_codec_spk_event),
+};
+
static struct snd_soc_card *sun6i_codec_create_card(struct device *dev)
{
struct snd_soc_card *card;
+ int ret;
card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL);
if (!card)
@@ -1116,8 +1126,15 @@ static struct snd_soc_card *sun6i_codec_create_card(struct device *dev)
if (!card->dai_link)
return ERR_PTR(-ENOMEM);
- card->dev = dev;
- card->name = "A31 Audio Codec";
+ card->dev = dev;
+ card->name = "A31 Audio Codec";
+ card->dapm_widgets = sun6i_codec_card_dapm_widgets;
+ card->num_dapm_widgets = ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
+ card->fully_routed = true;
+
+ ret = snd_soc_of_parse_audio_routing(card, "allwinner,audio-routing");
+ if (ret)
+ dev_warn(dev, "failed to parse audio-routing: %d\n", ret);
return card;
};
--
2.10.1
^ permalink raw reply related
* Applied "ASoC: sun4i-codec: Add support for A31 analog microphone inputs" to the asoc tree
From: Mark Brown @ 2016-11-04 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103075556.29018-10-wens@csie.org>
The patch
ASoC: sun4i-codec: Add support for A31 analog microphone inputs
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From ecd5cdb4fd818b1cec55863d5de3683dad1c2f53 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Thu, 3 Nov 2016 15:55:51 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for A31 analog microphone
inputs
The A31 internal codec has 3 microphone outputs, of which MIC2 and MIC3
are muxed internally. The resulting two microphone inputs have separate
gain controls and mixer inputs.
The codec also has 2 microphone bias pins. HBIAS is specifically for the
headphone jack, which also supports headphone detection and control
buttons. These extra functions are not supported yet. The other, MBIAS,
is for all other analog microphones.
There is also mention of digital microphone support, but documentation
is scarce, and no hardware with it is available.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 70 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index a10251f4932e..f55718fe7c5b 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -776,6 +776,14 @@ static const struct snd_kcontrol_new sun6i_codec_mixer_controls[] = {
SUN6I_CODEC_OM_DACA_CTRL,
SUN6I_CODEC_OM_DACA_CTRL_LMIX_LINEINL,
SUN6I_CODEC_OM_DACA_CTRL_RMIX_LINEINR, 1, 0),
+ SOC_DAPM_DOUBLE("Mic1 Playback Switch",
+ SUN6I_CODEC_OM_DACA_CTRL,
+ SUN6I_CODEC_OM_DACA_CTRL_LMIX_MIC1,
+ SUN6I_CODEC_OM_DACA_CTRL_RMIX_MIC1, 1, 0),
+ SOC_DAPM_DOUBLE("Mic2 Playback Switch",
+ SUN6I_CODEC_OM_DACA_CTRL,
+ SUN6I_CODEC_OM_DACA_CTRL_LMIX_MIC2,
+ SUN6I_CODEC_OM_DACA_CTRL_RMIX_MIC2, 1, 0),
};
/* headphone controls */
@@ -794,6 +802,21 @@ static const struct snd_kcontrol_new sun6i_codec_hp_src[] = {
sun6i_codec_hp_src_enum),
};
+/* microphone controls */
+static const char * const sun6i_codec_mic2_src_enum_text[] = {
+ "Mic2", "Mic3",
+};
+
+static SOC_ENUM_SINGLE_DECL(sun6i_codec_mic2_src_enum,
+ SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC2SLT,
+ sun6i_codec_mic2_src_enum_text);
+
+static const struct snd_kcontrol_new sun6i_codec_mic2_src[] = {
+ SOC_DAPM_ENUM("Mic2 Amplifier Source Route",
+ sun6i_codec_mic2_src_enum),
+};
+
/* line out controls */
static const char * const sun6i_codec_lineout_src_enum_text[] = {
"Stereo", "Mono Differential",
@@ -819,6 +842,10 @@ static const DECLARE_TLV_DB_RANGE(sun6i_codec_lineout_vol_scale,
0, 1, TLV_DB_SCALE_ITEM(TLV_DB_GAIN_MUTE, 0, 1),
2, 31, TLV_DB_SCALE_ITEM(-4350, 150, 0),
);
+static const DECLARE_TLV_DB_RANGE(sun6i_codec_mic_gain_scale,
+ 0, 0, TLV_DB_SCALE_ITEM(0, 0, 0),
+ 1, 7, TLV_DB_SCALE_ITEM(2400, 300, 0),
+);
static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SOC_SINGLE_TLV("DAC Playback Volume", SUN4I_CODEC_DAC_DPC,
@@ -844,9 +871,42 @@ static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SOC_SINGLE_TLV("Line In Playback Volume",
SUN6I_CODEC_OM_PA_CTRL, SUN6I_CODEC_OM_PA_CTRL_LINEING,
0x7, 0, sun6i_codec_out_mixer_pregain_scale),
+ SOC_SINGLE_TLV("Mic1 Playback Volume",
+ SUN6I_CODEC_OM_PA_CTRL, SUN6I_CODEC_OM_PA_CTRL_MIC1G,
+ 0x7, 0, sun6i_codec_out_mixer_pregain_scale),
+ SOC_SINGLE_TLV("Mic2 Playback Volume",
+ SUN6I_CODEC_OM_PA_CTRL, SUN6I_CODEC_OM_PA_CTRL_MIC2G,
+ 0x7, 0, sun6i_codec_out_mixer_pregain_scale),
+
+ /* Microphone Amp boost gains */
+ SOC_SINGLE_TLV("Mic1 Boost Volume", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC1BOOST, 0x7, 0,
+ sun6i_codec_mic_gain_scale),
+ SOC_SINGLE_TLV("Mic2 Boost Volume", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC2BOOST, 0x7, 0,
+ sun6i_codec_mic_gain_scale),
};
static const struct snd_soc_dapm_widget sun6i_codec_codec_dapm_widgets[] = {
+ /* Microphone inputs */
+ SND_SOC_DAPM_INPUT("MIC1"),
+ SND_SOC_DAPM_INPUT("MIC2"),
+ SND_SOC_DAPM_INPUT("MIC3"),
+
+ /* Microphone Bias */
+ SND_SOC_DAPM_SUPPLY("HBIAS", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_HBIASEN, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("MBIAS", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MBIASEN, 0, NULL, 0),
+
+ /* Mic input path */
+ SND_SOC_DAPM_MUX("Mic2 Amplifier Source Route",
+ SND_SOC_NOPM, 0, 0, sun6i_codec_mic2_src),
+ SND_SOC_DAPM_PGA("Mic1 Amplifier", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC1AMPEN, 0, NULL, 0),
+ SND_SOC_DAPM_PGA("Mic2 Amplifier", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC2AMPEN, 0, NULL, 0),
+
/* Line In */
SND_SOC_DAPM_INPUT("LINEIN"),
@@ -893,15 +953,25 @@ static const struct snd_soc_dapm_route sun6i_codec_codec_dapm_routes[] = {
{ "Left DAC", NULL, "DAC Enable" },
{ "Right DAC", NULL, "DAC Enable" },
+ /* Microphone Routes */
+ { "Mic1 Amplifier", NULL, "MIC1"},
+ { "Mic2 Amplifier Source Route", "Mic2", "MIC2" },
+ { "Mic2 Amplifier Source Route", "Mic3", "MIC3" },
+ { "Mic2 Amplifier", NULL, "Mic2 Amplifier Source Route"},
+
/* Left Mixer Routes */
{ "Left Mixer", "DAC Playback Switch", "Left DAC" },
{ "Left Mixer", "DAC Reversed Playback Switch", "Right DAC" },
{ "Left Mixer", "Line In Playback Switch", "LINEIN" },
+ { "Left Mixer", "Mic1 Playback Switch", "Mic1 Amplifier" },
+ { "Left Mixer", "Mic2 Playback Switch", "Mic2 Amplifier" },
/* Right Mixer Routes */
{ "Right Mixer", "DAC Playback Switch", "Right DAC" },
{ "Right Mixer", "DAC Reversed Playback Switch", "Left DAC" },
{ "Right Mixer", "Line In Playback Switch", "LINEIN" },
+ { "Right Mixer", "Mic1 Playback Switch", "Mic1 Amplifier" },
+ { "Right Mixer", "Mic2 Playback Switch", "Mic2 Amplifier" },
/* Headphone Routes */
{ "Headphone Source Playback Route", "DAC", "Left DAC" },
--
2.10.1
^ permalink raw reply related
* Applied "ASoC: sun4i-codec: Add support for A31 Line Out playback" to the asoc tree
From: Mark Brown @ 2016-11-04 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103075556.29018-9-wens@csie.org>
The patch
ASoC: sun4i-codec: Add support for A31 Line Out playback
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 0f909f98d7cbabc3641a45da9c6891444b929a92 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Thu, 3 Nov 2016 15:55:50 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for A31 Line Out playback
The A31 integrated codec has a second "Line Out" output which does not
include an integrated amplifier in its path. This path does have a
separate volume control.
This patch adds support for the playback path from the DAC to the Line
Out pins.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 72a84f76aa57..a10251f4932e 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -794,11 +794,31 @@ static const struct snd_kcontrol_new sun6i_codec_hp_src[] = {
sun6i_codec_hp_src_enum),
};
+/* line out controls */
+static const char * const sun6i_codec_lineout_src_enum_text[] = {
+ "Stereo", "Mono Differential",
+};
+
+static SOC_ENUM_DOUBLE_DECL(sun6i_codec_lineout_src_enum,
+ SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTLSRC,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTRSRC,
+ sun6i_codec_lineout_src_enum_text);
+
+static const struct snd_kcontrol_new sun6i_codec_lineout_src[] = {
+ SOC_DAPM_ENUM("Line Out Source Playback Route",
+ sun6i_codec_lineout_src_enum),
+};
+
/* volume / mute controls */
static const DECLARE_TLV_DB_SCALE(sun6i_codec_dvol_scale, -7308, 116, 0);
static const DECLARE_TLV_DB_SCALE(sun6i_codec_hp_vol_scale, -6300, 100, 1);
static const DECLARE_TLV_DB_SCALE(sun6i_codec_out_mixer_pregain_scale,
-450, 150, 0);
+static const DECLARE_TLV_DB_RANGE(sun6i_codec_lineout_vol_scale,
+ 0, 1, TLV_DB_SCALE_ITEM(TLV_DB_GAIN_MUTE, 0, 1),
+ 2, 31, TLV_DB_SCALE_ITEM(-4350, 150, 0),
+);
static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SOC_SINGLE_TLV("DAC Playback Volume", SUN4I_CODEC_DAC_DPC,
@@ -808,10 +828,18 @@ static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SUN6I_CODEC_OM_DACA_CTRL,
SUN6I_CODEC_OM_DACA_CTRL_HPVOL, 0x3f, 0,
sun6i_codec_hp_vol_scale),
+ SOC_SINGLE_TLV("Line Out Playback Volume",
+ SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTVC, 0x1f, 0,
+ sun6i_codec_lineout_vol_scale),
SOC_DOUBLE("Headphone Playback Switch",
SUN6I_CODEC_OM_DACA_CTRL,
SUN6I_CODEC_OM_DACA_CTRL_LHPPAMUTE,
SUN6I_CODEC_OM_DACA_CTRL_RHPPAMUTE, 1, 0),
+ SOC_DOUBLE("Line Out Playback Switch",
+ SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTLEN,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTREN, 1, 0),
/* Mixer pre-gains */
SOC_SINGLE_TLV("Line In Playback Volume",
SUN6I_CODEC_OM_PA_CTRL, SUN6I_CODEC_OM_PA_CTRL_LINEING,
@@ -853,6 +881,11 @@ static const struct snd_soc_dapm_widget sun6i_codec_codec_dapm_widgets[] = {
SND_SOC_DAPM_REG(snd_soc_dapm_supply, "HPCOM", SUN6I_CODEC_OM_PA_CTRL,
SUN6I_CODEC_OM_PA_CTRL_HPCOM_CTL, 0x3, 0x3, 0),
SND_SOC_DAPM_OUTPUT("HP"),
+
+ /* Line Out path */
+ SND_SOC_DAPM_MUX("Line Out Source Playback Route",
+ SND_SOC_NOPM, 0, 0, sun6i_codec_lineout_src),
+ SND_SOC_DAPM_OUTPUT("LINEOUT"),
};
static const struct snd_soc_dapm_route sun6i_codec_codec_dapm_routes[] = {
@@ -878,6 +911,12 @@ static const struct snd_soc_dapm_route sun6i_codec_codec_dapm_routes[] = {
{ "Headphone Amp", NULL, "Headphone Source Playback Route" },
{ "HP", NULL, "Headphone Amp" },
{ "HPCOM", NULL, "HPCOM Protection" },
+
+ /* Line Out Routes */
+ { "Line Out Source Playback Route", "Stereo", "Left Mixer" },
+ { "Line Out Source Playback Route", "Stereo", "Right Mixer" },
+ { "Line Out Source Playback Route", "Mono Differential", "Left Mixer" },
+ { "LINEOUT", NULL, "Line Out Source Playback Route" },
};
static struct snd_soc_codec_driver sun6i_codec_codec = {
--
2.10.1
^ permalink raw reply related
* [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Kevin Hilman @ 2016-11-04 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477925138-23457-2-git-send-email-bgolaszewski@baylibre.com>
Bartosz Golaszewski <bgolaszewski@baylibre.com> writes:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [PATCH v2 2/5] ARM: bus: da8xx-mstpri: new driver
From: Kevin Hilman @ 2016-11-04 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477925138-23457-3-git-send-email-bgolaszewski@baylibre.com>
Bartosz Golaszewski <bgolaszewski@baylibre.com> writes:
> Create the driver for the da8xx master peripheral priority
> configuration and implement support for writing to the three
> Master Priority registers on da850 SoCs.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [PATCH] ARM: dts: imx6: Add imx-weim parameters to dtsi's
From: Fabio Estevam @ 2016-11-04 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478044305-5666-1-git-send-email-stillcompiling@gmail.com>
On Tue, Nov 1, 2016 at 9:51 PM, Joshua Clayton <stillcompiling@gmail.com> wrote:
> imx-weim should always set address-cells to 2,
> and size_cells to 1.
> On imx6, fsl,weim-cs-gpr will always be &gpr
>
> Set these common parameters in the dtsi file,
> rather than in a downstream dts.
>
> Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH v2 4/4] ARM: dts: imx28: Fix build warnings with W=1
From: Fabio Estevam @ 2016-11-04 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908140338.GD16911@tiger>
Hi Shawn,
On Thu, Sep 8, 2016 at 11:03 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> On Mon, Sep 05, 2016 at 04:27:50PM -0300, Fabio Estevam wrote:
>> diff --git a/arch/arm/boot/dts/imx28-tx28.dts b/arch/arm/boot/dts/imx28-tx28.dts
>> index 0ebbc83..b4d4dbb 100644
>> --- a/arch/arm/boot/dts/imx28-tx28.dts
>> +++ b/arch/arm/boot/dts/imx28-tx28.dts
>> @@ -35,7 +35,8 @@
>> usbotg = &usb0;
>> };
>>
>> - memory {
>> + memory at 0 {
>> + device_type = "memory";
>> reg = <0 0>; /* will be filled in by U-Boot */
>
> I'm curious to know if the unit-address will be fixed up or not when
> 'reg' property gets updated by U-Boot.
Should I resend this series and keep imx28-tx28.dts unmodified?
^ permalink raw reply
* [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules
From: Stephen Boyd @ 2016-11-04 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025011632.GA23876@b29397-desktop>
Quoting Peter Chen (2016-10-24 18:16:32)
> On Mon, Oct 24, 2016 at 12:48:24PM -0700, Stephen Boyd wrote:
> > Quoting Chen-Yu Tsai (2016-10-24 05:19:05)
> > > Hi,
> > >
> > > On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> > > > The ULPI bus can be built as a module, and it will soon be
> > > > calling these functions when it supports probing devices from DT.
> > > > Export them so they can be used by the ULPI module.
> > > >
> > > > Acked-by: Rob Herring <robh@kernel.org>
> > > > Cc: <devicetree@vger.kernel.org>
> > > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > > ---
> > > > drivers/of/device.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > > > index 8a22a253a830..6719ab35b62e 100644
> > > > --- a/drivers/of/device.c
> > > > +++ b/drivers/of/device.c
> > > > @@ -225,6 +225,7 @@ ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
> > > >
> > > > return tsize;
> > > > }
> > > > +EXPORT_SYMBOL_GPL(of_device_get_modalias);
> > > >
> > > > int of_device_request_module(struct device *dev)
> > > > {
> > > > @@ -290,6 +291,7 @@ void of_device_uevent(struct device *dev, struct kobj_uevent_env *env)
> > > > }
> > > > mutex_unlock(&of_mutex);
> > > > }
> > > > +EXPORT_SYMBOL_GPL(of_device_uevent_modalias);
> > >
> > > This is trailing the wrong function.
> > >
> >
> > Good catch. Must have been some bad rebase.
> >
> > Peter, can you fix it while applying or should I resend this patch?
> >
>
> But, this is device tree patch. I can only get chipidea part and other
> USB patches if Greg agrees.
>
Were you expecting Rob to take the drivers/of/* patches? Sorry I thought
Rob acked them so they could go through usb with the other changes.
^ permalink raw reply
* Low network throughput on i.MX28
From: Jörg Krause @ 2016-11-04 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1783642995.185945.5e54a2af-ba2c-4901-93f6-1967dd432939.open-xchange@email.1und1.de>
On Fri, 2016-11-04 at 20:30 +0100, Stefan Wahren wrote:
> Hi J?rg,
>
> > J?rg Krause <joerg.krause@embedded.rocks> hat am 4. November 2016
> > um 19:44
> > geschrieben:
> >
> >
> > Hi Shawn,
> >
> > On Wed, 2016-11-02 at 09:24 +0100, Stefan Wahren wrote:
> > > Am 02.11.2016 um 09:14 schrieb J?rg Krause:
> > > > On Sat, 2016-10-29 at 11:08 +0200, Stefan Wahren wrote:
> > > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 29.
> > > > > > Oktober
> > > > > > 2016
> > > > > > um 01:07
> > > > > > geschrieben:
> > > > > >
> > > > > >
> > > > > > You mentioned [1] an optimization in the Freescale vendor
> > > > > > Linux
> > > > > > kernel
> > > > > > [2]. I would really like to see this optimization in the
> > > > > > mainline
> > > > > > kernel.
> > > > > >
> > > > > > Did you ever tried to port this code from Freescale to
> > > > > > mainline?
> > > > >
> > > > > Yes, i tried once but i was frustrated soon because of the
> > > > > lot of
> > > > > required
> > > > > changes and resulting issues.
> > > >
> > > > I got the PIO mode working for the mxs-mmc driver. For this I
> > > > ported
> > > > the PIO code from the vendor kernel and removed the usage of
> > > > the
> > > > DMA
> > > > engine entirely.
> > >
> > > Good job
> > >
> > > >
> > > > Testing network bandwidth with iperf, I get about ~10Mbit/sec
> > > > with
> > > > PIO
> > > > mode compared to ~6.5Mbit/sec with DMA mode for UDP and about
> > > > ~6.5Mbit/sec compared to ~4.5Mbit/sec with DMA mode for TCP.
> > >
> > > And how about MMC / sd card performance?
> >
> > I noticed poor performance with the i.MX28 MMC and/or DMA driver
> > using
> > the mainline kernel compared to the vendor Freescale kernel 2.6.35.
> > I've seen that hou have added the drivers to mainline some years
> > ago.
> >
> > My custom i.MX28 board has a wifi chip attached to the SSP2
> > interface.
> > Comparing the bandwith with iperf I get >20Mbits/sec on the vendor
> > kernel and <5Mbits/sec on the mainline kernel.
>
> there is one thing about the clock handling. I noticed that the
> Vendor Kernel
> round up the clock frequency and the Mainline Kernel round down the
> clock
> frequency [1]. So don't trust the clock ratings from DT / board code.
> Better
> verify the register settings or check it with an osci.
>
> [1] - http://www.spinics.net/lists/linux-mmc/msg09132.html
I checked the clock rate setting by reading the register 0x80014070
(HW_SSP2_TIMING). CLOCK_DIVIDE is 0x2 and CLOCK_RATE is 0x0. As SSP CLK
is 96MHz this makes a clock rate of 48MHz.
There was a discussion on the mailing list [1] about that tasklets
might be slow.
J?rg
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox