* [PATCH v2 1/2] PCI: kirin: Add MSI support
From: Yao Chen @ 2018-05-09 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525854012-24228-1-git-send-email-chenyao11@huawei.com>
Add support for MSI.
Signed-off-by: Yao Chen <chenyao11@huawei.com>
---
drivers/pci/dwc/pcie-kirin.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
index d2970a0..4328efe 100644
--- a/drivers/pci/dwc/pcie-kirin.c
+++ b/drivers/pci/dwc/pcie-kirin.c
@@ -426,9 +426,28 @@ static int kirin_pcie_establish_link(struct pcie_port *pp)
return 0;
}
+static irqreturn_t kirin_pcie_msi_irq_handler(int irq, void *arg)
+{
+ struct pcie_port *pp = arg;
+
+ return dw_handle_msi_irq(pp);
+}
+
+static void kirin_pcie_msi_init(struct pcie_port *pp)
+{
+ dw_pcie_msi_init(pp);
+}
+
+static void kirin_pcie_enable_interrupts(struct pcie_port *pp)
+{
+ if (IS_ENABLED(CONFIG_PCI_MSI))
+ kirin_pcie_msi_init(pp);
+}
+
static int kirin_pcie_host_init(struct pcie_port *pp)
{
kirin_pcie_establish_link(pp);
+ kirin_pcie_enable_interrupts(pp);
return 0;
}
@@ -448,6 +467,26 @@ static int kirin_pcie_host_init(struct pcie_port *pp)
static int __init kirin_add_pcie_port(struct dw_pcie *pci,
struct platform_device *pdev)
{
+ int ret;
+
+ if (IS_ENABLED(CONFIG_PCI_MSI)) {
+ pci->pp.msi_irq = platform_get_irq(pdev, 0);
+ if (!pci->pp.msi_irq) {
+ dev_err(&pdev->dev, "failed to get msi irq[%d]\n",
+ pci->pp.msi_irq);
+ return -ENODEV;
+ }
+ ret = devm_request_irq(&pdev->dev, pci->pp.msi_irq,
+ kirin_pcie_msi_irq_handler,
+ IRQF_SHARED | IRQF_NO_THREAD,
+ "kirin_pcie_msi", &pci->pp);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to request msi irq[%d]\n",
+ pci->pp.msi_irq);
+ return ret;
+ }
+ }
+
pci->pp.ops = &kirin_pcie_host_ops;
return dw_pcie_host_init(&pci->pp);
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: hi3660: Add pcie msi interrupt attribute
From: Yao Chen @ 2018-05-09 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525854012-24228-1-git-send-email-chenyao11@huawei.com>
Add pcie msi interrupt attribute for hi3660 SOC.
Signed-off-by: Yao Chen <chenyao11@huawei.com>
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index ec3eb8e..2cef8f4 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -872,6 +872,8 @@
0x0 0x02000000>;
num-lanes = <1>;
#interrupt-cells = <1>;
+ interrupts = <0 283 4>;
+ interrupt-names = "msi";
interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <0x0 0 0 1
&gic GIC_SPI 282 IRQ_TYPE_LEVEL_HIGH>,
--
1.9.1
^ permalink raw reply related
* [PATCH v7 15/24] ASoC: qdsp6: q6asm: Add support to memory map and unmap
From: Banajit Goswami @ 2018-05-09 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501120820.11016-16-srinivas.kandagatla@linaro.org>
On 5/1/2018 5:08 AM, Srinivas Kandagatla wrote:
> This patch adds support to memory map and unmap regions commands in
> q6asm module.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Reviewed-and-tested-by: Rohit kumar <rohitkr@codeaurora.org>
> ---
> sound/soc/qcom/qdsp6/q6asm.c | 349 +++++++++++++++++++++++++++++++++++++++++++
> sound/soc/qcom/qdsp6/q6asm.h | 5 +
> 2 files changed, 354 insertions(+)
>
> diff --git a/sound/soc/qcom/qdsp6/q6asm.c b/sound/soc/qcom/qdsp6/q6asm.c
> index c9526d2e59d2..5a573e927a5e 100644
> --- a/sound/soc/qcom/qdsp6/q6asm.c
> +++ b/sound/soc/qcom/qdsp6/q6asm.c
> @@ -18,10 +18,45 @@
> #include "q6dsp-errno.h"
> #include "q6dsp-common.h"
<snip>
> +
> +/**
> + * q6asm_map_memory_regions() - map memory regions in the dsp.
> + *
> + * @dir: direction of audio stream
> + * @ac: audio client instanace
> + * @phys: physcial address that needs mapping.
> + * @period_sz: audio period size
> + * @periods: number of periods
> + *
> + * Return: Will be an negative value on failure or zero on success
> + */
> +int q6asm_map_memory_regions(unsigned int dir, struct audio_client *ac,
> + phys_addr_t phys,
> + size_t period_sz, unsigned int periods)
> +{
> + struct audio_buffer *buf;
> + unsigned long flags;
> + int cnt;
> + int rc;
> +
> + spin_lock_irqsave(&ac->buf_lock, flags);
> + if (ac->port[dir].buf) {
> + dev_err(ac->dev, "Buffer already allocated\n");
> + spin_unlock_irqrestore(&ac->buf_lock, flags);
> + return 0;
> + }
> +
> + buf = kzalloc(((sizeof(struct audio_buffer)) * periods), GFP_ATOMIC);
> + if (!buf) {
> + spin_unlock_irqrestore(&ac->buf_lock, flags);
> + return -ENOMEM;
> + }
> +
> +
Remove extra blank line.
Otherwise LGTM.
Acked-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v6 07/15] KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing
From: Marc Zyngier @ 2018-05-09 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525797900-5548-8-git-send-email-Dave.Martin@arm.com>
On 08/05/18 17:44, Dave Martin wrote:
> This patch refactors KVM to align the host and guest FPSIMD
> save/restore logic with each other for arm64. This reduces the
> number of redundant save/restore operations that must occur, and
> reduces the common-case IRQ blackout time during guest exit storms
> by saving the host state lazily and optimising away the need to
> restore the host state before returning to the run loop.
>
> Four hooks are defined in order to enable this:
>
> * kvm_arch_vcpu_run_map_fp():
> Called on PID change to map necessary bits of current to Hyp.
>
> * kvm_arch_vcpu_load_fp():
> Set up FP/SIMD for entering the KVM run loop (parse as
> "vcpu_load fp").
>
> * kvm_arch_vcpu_ctxsync_fp():
> Get FP/SIMD into a safe state for re-enabling interrupts after a
> guest exit back to the run loop.
>
> For arm64 specifically, this involves updating the host kernel's
> FPSIMD context tracking metadata so that kernel-mode NEON use
> will cause the vcpu's FPSIMD state to be saved back correctly
> into the vcpu struct. This must be done before re-enabling
> interrupts because kernel-mode NEON may be used by softirqs.
>
> * kvm_arch_vcpu_put_fp():
> Save guest FP/SIMD state back to memory and dissociate from the
> CPU ("vcpu_put fp").
>
> Also, the arm64 FPSIMD context switch code is updated to enable it
> to save back FPSIMD state for a vcpu, not just current. A few
> helpers drive this:
>
> * fpsimd_bind_state_to_cpu(struct user_fpsimd_state *fp):
> mark this CPU as having context fp (which may belong to a vcpu)
> currently loaded in its registers. This is the non-task
> equivalent of the static function fpsimd_bind_to_cpu() in
> fpsimd.c.
>
> * task_fpsimd_save():
> exported to allow KVM to save the guest's FPSIMD state back to
> memory on exit from the run loop.
>
> * fpsimd_flush_state():
> invalidate any context's FPSIMD state that is currently loaded.
> Used to disassociate the vcpu from the CPU regs on run loop exit.
>
> These changes allow the run loop to enable interrupts (and thus
> softirqs that may use kernel-mode NEON) without having to save the
> guest's FPSIMD state eagerly.
>
> Some new vcpu_arch fields are added to make all this work. Because
> host FPSIMD state can now be saved back directly into current's
> thread_struct as appropriate, host_cpu_context is no longer used
> for preserving the FPSIMD state. However, it is still needed for
> preserving other things such as the host's system registers. To
> avoid ABI churn, the redundant storage space in host_cpu_context is
> not removed for now.
>
> arch/arm is not addressed by this patch and continues to use its
> current save/restore logic. It could provide implementations of
> the helpers later if desired.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
>
> ---
>
> Changes since v5:
>
> Requested by Marc Zyngier:
>
> * Migrate from adding new bool flags in vcpu_arch to adding bits in
> vcpu_arch.flags.
> ---
> arch/arm/include/asm/kvm_host.h | 8 +++
> arch/arm64/include/asm/fpsimd.h | 5 ++
> arch/arm64/include/asm/kvm_asm.h | 2 +
> arch/arm64/include/asm/kvm_host.h | 16 ++++++
> arch/arm64/kernel/fpsimd.c | 15 +++++-
> arch/arm64/kvm/Kconfig | 1 +
> arch/arm64/kvm/Makefile | 2 +-
> arch/arm64/kvm/fpsimd.c | 111 ++++++++++++++++++++++++++++++++++++++
> arch/arm64/kvm/hyp/switch.c | 50 +++++++++--------
> virt/kvm/arm/arm.c | 4 ++
> 10 files changed, 185 insertions(+), 29 deletions(-)
> create mode 100644 arch/arm64/kvm/fpsimd.c
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index c7c28c8..4cac8d1 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -303,6 +303,14 @@ int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
> int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
> struct kvm_device_attr *attr);
>
> +/*
> + * VFP/NEON switching is all done by the hyp switch code, so no need to
> + * coordinate with host context handling for this state:
> + */
> +static inline void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu) {}
> +static inline void kvm_arch_vcpu_park_fp(struct kvm_vcpu *vcpu) {}
> +static inline void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu) {}
> +
> /* All host FP/SIMD state is restored on guest exit, so nothing to save: */
> static inline void kvm_fpsimd_flush_cpu_state(void) {}
>
> diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
> index aa7162a..aa60895 100644
> --- a/arch/arm64/include/asm/fpsimd.h
> +++ b/arch/arm64/include/asm/fpsimd.h
> @@ -41,6 +41,8 @@ struct task_struct;
> extern void fpsimd_save_state(struct user_fpsimd_state *state);
> extern void fpsimd_load_state(struct user_fpsimd_state *state);
>
> +extern void fpsimd_save(void);
> +
> extern void fpsimd_thread_switch(struct task_struct *next);
> extern void fpsimd_flush_thread(void);
>
> @@ -49,7 +51,10 @@ extern void fpsimd_preserve_current_state(void);
> extern void fpsimd_restore_current_state(void);
> extern void fpsimd_update_current_state(struct user_fpsimd_state const *state);
>
> +extern void fpsimd_bind_state_to_cpu(struct user_fpsimd_state *state);
> +
> extern void fpsimd_flush_task_state(struct task_struct *target);
> +extern void fpsimd_flush_cpu_state(void);
> extern void sve_flush_cpu_state(void);
>
> /* Maximum VL that SVE VL-agnostic software can transparently support */
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index 9699c13..6429eb6 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -33,6 +33,8 @@
> /* vcpu_arch flags field values: */
> #define KVM_ARM64_DEBUG_DIRTY_SHIFT 0
> #define KVM_ARM64_DEBUG_DIRTY (1 << KVM_ARM64_DEBUG_DIRTY_SHIFT)
At some point, we could remove KVM_ARM64_DEBUG_DIRTY_SHIFT as it is not
used anymore (since 1ea66d27e7b0). Do not respin on this account though.
> +#define KVM_ARM64_FP_ENABLED (1 << 1) /* guest FP regs loaded */
> +#define KVM_ARM64_HOST_SVE_IN_USE (1 << 2) /* backup for host TIF_SVE */
>
> /* Translate a kernel address of @sym into its equivalent linear mapping */
> #define kvm_ksym_ref(sym) \
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index a5ed95c..e4bdc75 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -30,6 +30,7 @@
> #include <asm/kvm.h>
> #include <asm/kvm_asm.h>
> #include <asm/kvm_mmio.h>
> +#include <asm/thread_info.h>
>
> #define __KVM_HAVE_ARCH_INTC_INITIALIZED
>
> @@ -238,6 +239,10 @@ struct kvm_vcpu_arch {
>
> /* Pointer to host CPU context */
> kvm_cpu_context_t *host_cpu_context;
> +
> + struct thread_info *host_thread_info; /* hyp VA */
> + struct user_fpsimd_state *host_fpsimd_state; /* hyp VA */
> +
> struct {
> /* {Break,watch}point registers */
> struct kvm_guest_debug_arch regs;
> @@ -420,6 +425,17 @@ static inline void __cpu_init_stage2(void)
> "PARange is %d bits, unsupported configuration!", parange);
> }
>
> +/* Guest/host FPSIMD coordination helpers */
> +int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu);
> +void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu);
> +void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu);
> +void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu);
> +
> +static inline int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
> +{
> + return kvm_arch_vcpu_run_map_fp(vcpu);
> +}
> +
> /*
> * All host FP/SIMD state is restored on guest exit, so nothing needs
> * doing here except in the SVE case:
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 5fc0595..e7349b5 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -275,7 +275,7 @@ static void task_fpsimd_load(void)
> *
> * Softirqs (and preemption) must be disabled.
> */
> -static void fpsimd_save(void)
> +void fpsimd_save(void)
> {
> struct user_fpsimd_state *st = __this_cpu_read(fpsimd_last_state.st);
>
> @@ -1008,6 +1008,17 @@ static void fpsimd_bind_to_cpu(void)
> current->thread.fpsimd_cpu = smp_processor_id();
> }
>
> +void fpsimd_bind_state_to_cpu(struct user_fpsimd_state *st)
> +{
> + struct fpsimd_last_state_struct *last =
> + this_cpu_ptr(&fpsimd_last_state);
> +
> + WARN_ON(!in_softirq() && !irqs_disabled());
> +
> + last->st = st;
> + last->sve_in_use = false;
> +}
> +
> /*
> * Load the userland FPSIMD state of 'current' from memory, but only if the
> * FPSIMD state already held in the registers is /not/ the most recent FPSIMD
> @@ -1060,7 +1071,7 @@ void fpsimd_flush_task_state(struct task_struct *t)
> t->thread.fpsimd_cpu = NR_CPUS;
> }
>
> -static inline void fpsimd_flush_cpu_state(void)
> +void fpsimd_flush_cpu_state(void)
> {
> __this_cpu_write(fpsimd_last_state.st, NULL);
> }
> diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> index a2e3a5a..47b23bf 100644
> --- a/arch/arm64/kvm/Kconfig
> +++ b/arch/arm64/kvm/Kconfig
> @@ -39,6 +39,7 @@ config KVM
> select HAVE_KVM_IRQ_ROUTING
> select IRQ_BYPASS_MANAGER
> select HAVE_KVM_IRQ_BYPASS
> + select HAVE_KVM_VCPU_RUN_PID_CHANGE
> ---help---
> Support hosting virtualized guest machines.
> We don't support KVM with 16K page tables yet, due to the multiple
> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> index 93afff9..0f2a135 100644
> --- a/arch/arm64/kvm/Makefile
> +++ b/arch/arm64/kvm/Makefile
> @@ -19,7 +19,7 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/psci.o $(KVM)/arm/perf.o
> kvm-$(CONFIG_KVM_ARM_HOST) += inject_fault.o regmap.o va_layout.o
> kvm-$(CONFIG_KVM_ARM_HOST) += hyp.o hyp-init.o handle_exit.o
> kvm-$(CONFIG_KVM_ARM_HOST) += guest.o debug.o reset.o sys_regs.o sys_regs_generic_v8.o
> -kvm-$(CONFIG_KVM_ARM_HOST) += vgic-sys-reg-v3.o
> +kvm-$(CONFIG_KVM_ARM_HOST) += vgic-sys-reg-v3.o fpsimd.o
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/aarch32.o
>
> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic.o
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> new file mode 100644
> index 0000000..7059275
> --- /dev/null
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -0,0 +1,111 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * arch/arm64/kvm/fpsimd.c: Guest/host FPSIMD context coordination helpers
> + *
> + * Copyright 2018 Arm Limited
> + * Author: Dave Martin <Dave.Martin@arm.com>
> + */
> +#include <linux/bottom_half.h>
> +#include <linux/sched.h>
> +#include <linux/thread_info.h>
> +#include <linux/kvm_host.h>
> +#include <asm/kvm_asm.h>
> +#include <asm/kvm_host.h>
> +#include <asm/kvm_mmu.h>
> +
> +/*
> + * Called on entry to KVM_RUN unless this vcpu previously ran at least
> + * once and the most recent prior KVM_RUN for this vcpu was called from
> + * the same task as current (highly likely).
> + *
> + * This is guaranteed to execute before kvm_arch_vcpu_load_fp(vcpu),
> + * such that on entering hyp the relevant parts of current are already
> + * mapped.
> + */
> +int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu)
> +{
> + int ret;
> +
> + struct thread_info *ti = ¤t->thread_info;
> + struct user_fpsimd_state *fpsimd = ¤t->thread.uw.fpsimd_state;
> +
> + /*
> + * Make sure the host task thread flags and fpsimd state are
> + * visible to hyp:
> + */
> + ret = create_hyp_mappings(ti, ti + 1, PAGE_HYP);
> + if (ret)
> + goto error;
> +
> + ret = create_hyp_mappings(fpsimd, fpsimd + 1, PAGE_HYP);
> + if (ret)
> + goto error;
> +
> + vcpu->arch.host_thread_info = kern_hyp_va(ti);
> + vcpu->arch.host_fpsimd_state = kern_hyp_va(fpsimd);
Since we assign host_fpsimd_state here, and that "map" is guaranteed to
execute before "load"...
> +error:
> + return ret;
> +}
> +
> +/*
> + * Prepare vcpu for saving the host's FPSIMD state and loading the guest's.
> + * The actual loading is done by the FPSIMD access trap taken to hyp.
> + *
> + * Here, we just set the correct metadata to indicate that the FPSIMD
> + * state in the cpu regs (if any) belongs to current, and where to write
> + * it back to if/when a FPSIMD access trap is taken.
> + *
> + * TIF_SVE is backed up here, since it may get clobbered with guest state.
> + * This flag is restored by kvm_arch_vcpu_put_fp(vcpu).
> + */
> +void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
> +{
> + BUG_ON(system_supports_sve());
> + BUG_ON(!current->mm);
> +
> + vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED | KVM_ARM64_HOST_SVE_IN_USE);
> + if (test_thread_flag(TIF_SVE))
> + vcpu->arch.flags |= KVM_ARM64_HOST_SVE_IN_USE;
> +
> + vcpu->arch.host_fpsimd_state =
> + kern_hyp_va(¤t->thread.uw.fpsimd_state);
... what is the purpose of this assignment? I don't think it is harmful
in any way, but I'm just wondering if I'm missing in the actual flow.
> +}
> +
> +/*
> + * If the guest FPSIMD state was loaded, update the host's context
> + * tracking data mark the CPU FPSIMD regs as dirty for vcpu so that they
> + * will be written back if the kernel clobbers them due to kernel-mode
> + * NEON before re-entry into the guest.
> + */
> +void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu)
> +{
> + WARN_ON_ONCE(!irqs_disabled());
> +
> + if (vcpu->arch.flags & KVM_ARM64_FP_ENABLED) {
> + fpsimd_bind_state_to_cpu(&vcpu->arch.ctxt.gp_regs.fp_regs);
> + clear_thread_flag(TIF_FOREIGN_FPSTATE);
> + clear_thread_flag(TIF_SVE);
> + }
> +}
> +
> +/*
> + * Write back the vcpu FPSIMD regs if they are dirty, and invalidate the
> + * cpu FPSIMD regs so that they can't be spuriously reused if this vcpu
> + * disappears and another task or vcpu appears that recycles the same
> + * struct fpsimd_state.
> + */
> +void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
> +{
> + local_bh_disable();
> +
> + if (vcpu->arch.flags & KVM_ARM64_FP_ENABLED) {
> + fpsimd_save();
> + fpsimd_flush_cpu_state();
> + set_thread_flag(TIF_FOREIGN_FPSTATE);
> + }
> +
> + update_thread_flag(TIF_SVE,
> + vcpu->arch.flags & KVM_ARM64_HOST_SVE_IN_USE);
Does this indicate anything about the validity of the SVE registers? Or
is it for the sole purpose of userspace not having to trap to re-enable SVE?
> +
> + local_bh_enable();
> +}
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index c0796c4..75c3b65 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -27,15 +27,16 @@
> #include <asm/kvm_mmu.h>
> #include <asm/fpsimd.h>
> #include <asm/debug-monitors.h>
> +#include <asm/thread_info.h>
>
> -static bool __hyp_text __fpsimd_enabled_nvhe(void)
> +static bool __hyp_text update_fp_enabled(struct kvm_vcpu *vcpu)
> {
> - return !(read_sysreg(cptr_el2) & CPTR_EL2_TFP);
> -}
> + if (vcpu->arch.host_thread_info->flags & _TIF_FOREIGN_FPSTATE) {
> + vcpu->arch.host_fpsimd_state = NULL;
> + vcpu->arch.flags &= ~KVM_ARM64_FP_ENABLED;
> + }
I must confess I don't get this bit. If we started off with an invalid
host state (which is how I interpret TIF_FOREIGN_FPSTATE), why didn't we
simply zero the pointer at load time? The thread flag cannot change in
the meantime, right? Or did I get that wrong?
>
> -static bool fpsimd_enabled_vhe(void)
> -{
> - return !!(read_sysreg(cpacr_el1) & CPACR_EL1_FPEN);
> + return !!(vcpu->arch.flags & KVM_ARM64_FP_ENABLED);
> }
>
> /* Save the 32-bit only FPSIMD system register state */
> @@ -92,7 +93,10 @@ static void activate_traps_vhe(struct kvm_vcpu *vcpu)
>
> val = read_sysreg(cpacr_el1);
> val |= CPACR_EL1_TTA;
> - val &= ~(CPACR_EL1_FPEN | CPACR_EL1_ZEN);
> + val &= ~CPACR_EL1_ZEN;
> + if (!update_fp_enabled(vcpu))
> + val &= ~CPACR_EL1_FPEN;
> +
> write_sysreg(val, cpacr_el1);
>
> write_sysreg(kvm_get_hyp_vector(), vbar_el1);
> @@ -105,7 +109,10 @@ static void __hyp_text __activate_traps_nvhe(struct kvm_vcpu *vcpu)
> __activate_traps_common(vcpu);
>
> val = CPTR_EL2_DEFAULT;
> - val |= CPTR_EL2_TTA | CPTR_EL2_TFP | CPTR_EL2_TZ;
> + val |= CPTR_EL2_TTA | CPTR_EL2_TZ;
> + if (!update_fp_enabled(vcpu))
> + val |= CPTR_EL2_TFP;
> +
> write_sysreg(val, cptr_el2);
> }
>
> @@ -321,8 +328,6 @@ static bool __hyp_text __skip_instr(struct kvm_vcpu *vcpu)
> void __hyp_text __hyp_switch_fpsimd(u64 esr __always_unused,
> struct kvm_vcpu *vcpu)
> {
> - kvm_cpu_context_t *host_ctxt;
> -
> if (has_vhe())
> write_sysreg(read_sysreg(cpacr_el1) | CPACR_EL1_FPEN,
> cpacr_el1);
> @@ -332,14 +337,19 @@ void __hyp_text __hyp_switch_fpsimd(u64 esr __always_unused,
>
> isb();
>
> - host_ctxt = kern_hyp_va(vcpu->arch.host_cpu_context);
> - __fpsimd_save_state(&host_ctxt->gp_regs.fp_regs);
> + if (vcpu->arch.host_fpsimd_state) {
> + __fpsimd_save_state(vcpu->arch.host_fpsimd_state);
> + vcpu->arch.host_fpsimd_state = NULL;
> + }
> +
> __fpsimd_restore_state(&vcpu->arch.ctxt.gp_regs.fp_regs);
>
> /* Skip restoring fpexc32 for AArch64 guests */
> if (!(read_sysreg(hcr_el2) & HCR_RW))
> write_sysreg(vcpu->arch.ctxt.sys_regs[FPEXC32_EL2],
> fpexc32_el2);
> +
> + vcpu->arch.flags |= KVM_ARM64_FP_ENABLED;
> }
>
> /*
> @@ -418,7 +428,6 @@ int kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
> {
> struct kvm_cpu_context *host_ctxt;
> struct kvm_cpu_context *guest_ctxt;
> - bool fp_enabled;
> u64 exit_code;
>
> host_ctxt = vcpu->arch.host_cpu_context;
> @@ -440,19 +449,14 @@ int kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
> /* And we're baaack! */
> } while (fixup_guest_exit(vcpu, &exit_code));
>
> - fp_enabled = fpsimd_enabled_vhe();
> -
> sysreg_save_guest_state_vhe(guest_ctxt);
>
> __deactivate_traps(vcpu);
>
> sysreg_restore_host_state_vhe(host_ctxt);
>
> - if (fp_enabled) {
> - __fpsimd_save_state(&guest_ctxt->gp_regs.fp_regs);
> - __fpsimd_restore_state(&host_ctxt->gp_regs.fp_regs);
> + if (vcpu->arch.flags & KVM_ARM64_FP_ENABLED)
> __fpsimd_save_fpexc32(vcpu);
> - }
>
> __debug_switch_to_host(vcpu);
>
> @@ -464,7 +468,6 @@ int __hyp_text __kvm_vcpu_run_nvhe(struct kvm_vcpu *vcpu)
> {
> struct kvm_cpu_context *host_ctxt;
> struct kvm_cpu_context *guest_ctxt;
> - bool fp_enabled;
> u64 exit_code;
>
> vcpu = kern_hyp_va(vcpu);
> @@ -496,8 +499,6 @@ int __hyp_text __kvm_vcpu_run_nvhe(struct kvm_vcpu *vcpu)
> /* And we're baaack! */
> } while (fixup_guest_exit(vcpu, &exit_code));
>
> - fp_enabled = __fpsimd_enabled_nvhe();
> -
> __sysreg_save_state_nvhe(guest_ctxt);
> __sysreg32_save_state(vcpu);
> __timer_disable_traps(vcpu);
> @@ -508,11 +509,8 @@ int __hyp_text __kvm_vcpu_run_nvhe(struct kvm_vcpu *vcpu)
>
> __sysreg_restore_state_nvhe(host_ctxt);
>
> - if (fp_enabled) {
> - __fpsimd_save_state(&guest_ctxt->gp_regs.fp_regs);
> - __fpsimd_restore_state(&host_ctxt->gp_regs.fp_regs);
> + if (vcpu->arch.flags & KVM_ARM64_FP_ENABLED)
> __fpsimd_save_fpexc32(vcpu);
> - }
>
> /*
> * This must come after restoring the host sysregs, since a non-VHE
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index a4c1b76..bee226c 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -363,10 +363,12 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> kvm_vgic_load(vcpu);
> kvm_timer_vcpu_load(vcpu);
> kvm_vcpu_load_sysregs(vcpu);
> + kvm_arch_vcpu_load_fp(vcpu);
> }
>
> void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
> {
> + kvm_arch_vcpu_put_fp(vcpu);
> kvm_vcpu_put_sysregs(vcpu);
> kvm_timer_vcpu_put(vcpu);
> kvm_vgic_put(vcpu);
> @@ -778,6 +780,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
> if (static_branch_unlikely(&userspace_irqchip_in_use))
> kvm_timer_sync_hwstate(vcpu);
>
> + kvm_arch_vcpu_ctxsync_fp(vcpu);
> +
> /*
> * We may have taken a host interrupt in HYP mode (ie
> * while executing the guest). This interrupt is still
>
It otherwise looks good, and I don't think the above nits are
problematic on their own.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v6 06/15] KVM: arm64: Repurpose vcpu_arch.debug_flags for general-purpose flags
From: Marc Zyngier @ 2018-05-09 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525797900-5548-7-git-send-email-Dave.Martin@arm.com>
On 08/05/18 17:44, Dave Martin wrote:
> In struct vcpu_arch, the debug_flags field is used to store debug-
> related flags about the vcpu state.
>
> Since we are about to add some more flags related to FPSIMD and
> SVE, it makes sense to add them to the existing flags field rather
> than adding new fields. Since there is only one debug_flags flag
> defined so far, there is plenty of free space for expansion.
>
> In preparation for adding more flags, this patch renames the
> debug_flags field to simply "flags", and updates comments
> appropriately.
>
> No functional change.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v6 08/15] arm64/sve: Move read_zcr_features() out of cpufeature.h
From: Marc Zyngier @ 2018-05-09 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525797900-5548-9-git-send-email-Dave.Martin@arm.com>
On 08/05/18 17:44, Dave Martin wrote:
> Having read_zcr_features() inline in cpufeature.h results in that
> header requiring #includes which make it hard to include
> <asm/fpsimd.h> elsewhere without triggering header inclusion
> cycles.
>
> This is not a hot-path function and arguably should not be in
> cpufeature.h in the first place, so this patch moves it to
> fpsimd.c, compiled conditionally if CONFIG_ARM64_SVE=y.
>
> This allows some SVE-related #includes to be dropped from
> cpufeature.h, which will ease future maintenance.
>
> A couple of missing #includes of <asm/fpsimd.h> are exposed by this
> change under arch/arm64/. This patch adds the missing #includes as
> necessary.
>
> No functional change.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v7 19/24] ASoC: qdsp6: q6routing: Add support to MI2S Mixers
From: Banajit Goswami @ 2018-05-09 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501120820.11016-20-srinivas.kandagatla@linaro.org>
On 5/1/2018 5:08 AM, Srinivas Kandagatla wrote:
> This patch add support to MI2S mixers required to select path between
> ASM stream and AFE ports.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Reviewed-and-tested-by: Rohit kumar <rohitkr@codeaurora.org>
> ---
> sound/soc/qcom/qdsp6/q6routing.c | 329 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 329 insertions(+)
>
>
Acked-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Applied "ASoC: fix return value check in mt6351_codec_driver_probe()" to the asoc tree
From: Mark Brown @ 2018-05-09 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525657185-73163-1-git-send-email-weiyongjun1@huawei.com>
The patch
ASoC: fix return value check in mt6351_codec_driver_probe()
has been applied to the asoc tree at
https://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 aaa730ca3f88f535dc12e2f0ff575f70f516841b Mon Sep 17 00:00:00 2001
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Mon, 7 May 2018 01:39:45 +0000
Subject: [PATCH] ASoC: fix return value check in mt6351_codec_driver_probe()
In case of error, the function dev_get_regmap() returns NULL pointer not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/codecs/mt6351.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/mt6351.c b/sound/soc/codecs/mt6351.c
index e739f078fec5..f73dcd753584 100644
--- a/sound/soc/codecs/mt6351.c
+++ b/sound/soc/codecs/mt6351.c
@@ -1472,8 +1472,8 @@ static int mt6351_codec_driver_probe(struct platform_device *pdev)
priv->dev = &pdev->dev;
priv->regmap = dev_get_regmap(pdev->dev.parent, NULL);
- if (IS_ERR(priv->regmap))
- return PTR_ERR(priv->regmap);
+ if (!priv->regmap)
+ return -ENODEV;
dev_dbg(priv->dev, "%s(), dev name %s\n",
__func__, dev_name(&pdev->dev));
--
2.17.0
^ permalink raw reply related
* [PATCH v7 18/24] ASoC: qdsp6: q6routing: Add support to all SLIMBus Mixers
From: Banajit Goswami @ 2018-05-09 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501120820.11016-19-srinivas.kandagatla@linaro.org>
On 5/1/2018 5:08 AM, Srinivas Kandagatla wrote:
> This patch adds support to SLIMBus related mixers to control mux between
> ASM stream and AFE port.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Reviewed-and-tested-by: Rohit kumar <rohitkr@codeaurora.org>
> ---
> sound/soc/qcom/qdsp6/q6routing.c | 261 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 261 insertions(+)
>
>
Acked-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v6 09/15] arm64/sve: Switch sve_pffr() argument from task to thread
From: Marc Zyngier @ 2018-05-09 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525797900-5548-10-git-send-email-Dave.Martin@arm.com>
On 08/05/18 17:44, Dave Martin wrote:
> sve_pffr(), which is used to derive the base address used for
> low-level SVE save/restore routines, currently takes the relevant
> task_struct as an argument.
>
> The only accessed fields are actually part of thread_struct, so
> this patch changes the argument type accordingly. This is done in
> preparation for moving this function to a header, where we do not
> want to have to include <linux/sched.h> due to the consequent
> circular #include problems.
>
> No functional change.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v6 10/15] arm64/sve: Move sve_pffr() to fpsimd.h and make inline
From: Marc Zyngier @ 2018-05-09 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525797900-5548-11-git-send-email-Dave.Martin@arm.com>
On 08/05/18 17:44, Dave Martin wrote:
> In order to make sve_save_state()/sve_load_state() more easily
> reusable and to get rid of a potential branch on context switch
> critical paths, this patch makes sve_pffr() inline and moves it to
> fpsimd.h.
>
> <asm/processor.h> must be included in fpsimd.h in order to make
> this work, and this creates an #include cycle that is tricky to
> avoid without modifying core code, due to the way the PR_SVE_*()
> prctl helpers are included in the core prctl implementation.
>
> Instead of breaking the cycle, this patch defers inclusion of
> <asm/fpsimd.h> in <asm/processor.h> until the point where it is
> actually needed: i.e., immediately before the prctl definitions.
>
> No functional change.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v6 11/15] KVM: arm64: Save host SVE context as appropriate
From: Marc Zyngier @ 2018-05-09 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525797900-5548-12-git-send-email-Dave.Martin@arm.com>
On 08/05/18 17:44, Dave Martin wrote:
> This patch adds SVE context saving to the hyp FPSIMD context switch
> path. This means that it is no longer necessary to save the host
> SVE state in advance of entering the guest, when in use.
>
> In order to avoid adding pointless complexity to the code, VHE is
> assumed if SVE is in use. VHE is an architectural prerequisite for
> SVE, so there is no good reason to turn CONFIG_ARM64_VHE off in
> kernels that support both SVE and KVM.
>
> Historically, software models exist that can expose the
> architecturally invalid configuration of SVE without VHE, so if
> this situation is detected this patch warns and refuses to create a
> VM. Doing this check at VM creation time avoids race issues
> between KVM and SVE initialisation.
I don't think the commit log now reflects the code, since we bail out at
init time and disable KVM altogether.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
>
> ---
>
> Changes since v5:
>
> Requested by Marc Zyngier:
>
> * Migrate to flag bits in vcpu_arch.flags instead of adding bools in
> vcpu_arch.
>
> * Move system_supports_sve() && !has_vhe() sanity check to
> kvm_arch_init() instead of doing it each time a VM is created.
> cpufeatures initialisation should be complete by the time any
> before module_init() call runs.
> ---
> arch/arm64/Kconfig | 7 +++++++
> arch/arm64/kvm/fpsimd.c | 1 -
> arch/arm64/kvm/hyp/switch.c | 22 ++++++++++++++++++++--
> virt/kvm/arm/arm.c | 18 ++++++++++++++++++
> 4 files changed, 45 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index eb2cf49..b0d3820 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1130,6 +1130,7 @@ endmenu
> config ARM64_SVE
> bool "ARM Scalable Vector Extension support"
> default y
> + depends on !KVM || ARM64_VHE
> help
> The Scalable Vector Extension (SVE) is an extension to the AArch64
> execution state which complements and extends the SIMD functionality
> @@ -1155,6 +1156,12 @@ config ARM64_SVE
> booting the kernel. If unsure and you are not observing these
> symptoms, you should assume that it is safe to say Y.
>
> + CPUs that support SVE are architecturally required to support the
> + Virtualization Host Extensions (VHE), so the kernel makes no
> + provision for supporting SVE alongside KVM without VHE enabled.
> + Thus, you will need to enable CONFIG_ARM64_VHE if you want to support
> + KVM in the same kernel image.
> +
> config ARM64_MODULE_PLTS
> bool
> select HAVE_MOD_ARCH_SPECIFIC
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index 7059275..4c47b55 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -60,7 +60,6 @@ int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu)
> */
> void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
> {
> - BUG_ON(system_supports_sve());
> BUG_ON(!current->mm);
>
> vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED | KVM_ARM64_HOST_SVE_IN_USE);
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 75c3b65..6826f2d 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -21,12 +21,14 @@
>
> #include <kvm/arm_psci.h>
>
> +#include <asm/cpufeature.h>
> #include <asm/kvm_asm.h>
> #include <asm/kvm_emulate.h>
> #include <asm/kvm_hyp.h>
> #include <asm/kvm_mmu.h>
> #include <asm/fpsimd.h>
> #include <asm/debug-monitors.h>
> +#include <asm/processor.h>
> #include <asm/thread_info.h>
>
> static bool __hyp_text update_fp_enabled(struct kvm_vcpu *vcpu)
> @@ -328,6 +330,8 @@ static bool __hyp_text __skip_instr(struct kvm_vcpu *vcpu)
> void __hyp_text __hyp_switch_fpsimd(u64 esr __always_unused,
> struct kvm_vcpu *vcpu)
> {
> + struct user_fpsimd_state *host_fpsimd = vcpu->arch.host_fpsimd_state;
> +
> if (has_vhe())
> write_sysreg(read_sysreg(cpacr_el1) | CPACR_EL1_FPEN,
> cpacr_el1);
> @@ -337,8 +341,22 @@ void __hyp_text __hyp_switch_fpsimd(u64 esr __always_unused,
>
> isb();
>
> - if (vcpu->arch.host_fpsimd_state) {
> - __fpsimd_save_state(vcpu->arch.host_fpsimd_state);
> + if (host_fpsimd) {
> + /*
> + * In the SVE case, VHE is assumed: it is enforced by
> + * Kconfig and kvm_arch_init_vm().
Nit: this is now kvm_arch_init().
> + */
> + if (system_supports_sve() &&
> + (vcpu->arch.flags & KVM_ARM64_HOST_SVE_IN_USE)) {
> + struct thread_struct *thread = container_of(
> + host_fpsimd,
> + struct thread_struct, uw.fpsimd_state);
> +
> + sve_save_state(sve_pffr(thread), &host_fpsimd->fpsr);
> + } else {
> + __fpsimd_save_state(vcpu->arch.host_fpsimd_state);
> + }
> +
> vcpu->arch.host_fpsimd_state = NULL;
> }
>
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index bee226c..379e8a9 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -16,6 +16,7 @@
> * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
> */
>
> +#include <linux/bug.h>
> #include <linux/cpu_pm.h>
> #include <linux/errno.h>
> #include <linux/err.h>
> @@ -41,6 +42,7 @@
> #include <asm/mman.h>
> #include <asm/tlbflush.h>
> #include <asm/cacheflush.h>
> +#include <asm/cpufeature.h>
> #include <asm/virt.h>
> #include <asm/kvm_arm.h>
> #include <asm/kvm_asm.h>
> @@ -1582,6 +1584,22 @@ int kvm_arch_init(void *opaque)
> }
> }
>
> + /*
> + * VHE is a prerequisite for SVE in the Arm architecture, and
> + * Kconfig ensures that if system_supports_sve() here then
> + * CONFIG_ARM64_VHE is enabled, so if VHE support wasn't already
> + * detected and enabled, the CPU is architecturally
> + * noncompliant.
> + *
> + * Just in case this mismatch is seen, detect it, warn and give
> + * up. Supporting this forbidden configuration in Hyp would be
> + * pointless.
> + */
> + if (system_supports_sve() && !has_vhe()) {
> + kvm_pr_unimpl("SVE system without VHE unsupported. Broken cpu?");
> + return -ENODEV;
> + }
> +
> err = init_common_resources();
> if (err)
> return err;
>
Otherwise:
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v7 17/24] ASoC: qdsp6: q6routing: Add q6routing driver
From: Banajit Goswami @ 2018-05-09 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501120820.11016-18-srinivas.kandagatla@linaro.org>
On 5/1/2018 5:08 AM, Srinivas Kandagatla wrote:
> This patch adds support to q6 routing driver which configures route
> between ASM and AFE module using ADM apis.
>
> This driver uses dapm widgets to setup the matrix between AFE ports and
> ASM streams.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Reviewed-and-tested-by: Rohit kumar <rohitkr@codeaurora.org>
> ---
> sound/soc/qcom/Kconfig | 4 +
> sound/soc/qcom/qdsp6/Makefile | 1 +
> sound/soc/qcom/qdsp6/q6routing.c | 393 +++++++++++++++++++++++++++++++++++++++
> sound/soc/qcom/qdsp6/q6routing.h | 9 +
> 4 files changed, 407 insertions(+)
> create mode 100644 sound/soc/qcom/qdsp6/q6routing.c
> create mode 100644 sound/soc/qcom/qdsp6/q6routing.h
>
> diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
> index 941774abd94f..43f9ed85efa8 100644
> --- a/sound/soc/qcom/Kconfig
> +++ b/sound/soc/qcom/Kconfig
> @@ -53,6 +53,9 @@ config SND_SOC_QDSP6_AFE
> config SND_SOC_QDSP6_ADM
> tristate
>
> +config SND_SOC_QDSP6_ROUTING
> + tristate
> +
> config SND_SOC_QDSP6_ASM
> tristate
>
> @@ -63,6 +66,7 @@ config SND_SOC_QDSP6
> select SND_SOC_QDSP6_CORE
> select SND_SOC_QDSP6_AFE
> select SND_SOC_QDSP6_ADM
> + select SND_SOC_QDSP6_ROUTING
> select SND_SOC_QDSP6_ASM
> help
> To add support for MSM QDSP6 Soc Audio.
> diff --git a/sound/soc/qcom/qdsp6/Makefile b/sound/soc/qcom/qdsp6/Makefile
> index 01d9dcf3375c..0e8e2febb7ec 100644
> --- a/sound/soc/qcom/qdsp6/Makefile
> +++ b/sound/soc/qcom/qdsp6/Makefile
> @@ -2,4 +2,5 @@ obj-$(CONFIG_SND_SOC_QDSP6_COMMON) += q6dsp-common.o
> obj-$(CONFIG_SND_SOC_QDSP6_CORE) += q6core.o
> obj-$(CONFIG_SND_SOC_QDSP6_AFE) += q6afe.o
> obj-$(CONFIG_SND_SOC_QDSP6_ADM) += q6adm.o
> +obj-$(CONFIG_SND_SOC_QDSP6_ROUTING) += q6routing.o
> obj-$(CONFIG_SND_SOC_QDSP6_ASM) += q6asm.o
> diff --git a/sound/soc/qcom/qdsp6/q6routing.c b/sound/soc/qcom/qdsp6/q6routing.c
> new file mode 100644
> index 000000000000..72863672f11f
> --- /dev/null
> +++ b/sound/soc/qcom/qdsp6/q6routing.c
> @@ -0,0 +1,393 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2011-2017, The Linux Foundation. All rights reserved.
> +// Copyright (c) 2018, Linaro Limited
> +
> +#include <linux/init.h>
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/of_platform.h>
> +#include <linux/bitops.h>
> +#include <linux/component.h>
> +#include <linux/mutex.h>
> +#include <linux/of_device.h>
> +#include <linux/slab.h>
> +#include <sound/core.h>
> +#include <sound/soc.h>
> +#include <sound/soc-dapm.h>
> +#include <sound/pcm.h>
> +#include <sound/control.h>
> +#include <sound/asound.h>
> +#include <sound/pcm_params.h>
> +#include "q6afe.h"
> +#include "q6asm.h"
> +#include "q6adm.h"
> +#include "q6routing.h"
> +
> +#define DRV_NAME "q6routing-component"
> +
> +struct session_data {
> + int state;
> + int port_id;
> + int path_type;
> + int app_type;
> + int acdb_id;
> + int sample_rate;
> + int bits_per_sample;
> + int channels;
> + int perf_mode;
> + int numcopps;
> + int fedai_id;
> + unsigned long copp_map;
> +};
> +
> +struct msm_routing_data {
> + struct session_data sessions[MAX_SESSIONS];
> + struct session_data port_data[AFE_MAX_PORTS];
> + struct device *dev;
> + struct mutex lock;
> +};
> +
> +static struct msm_routing_data *routing_data;
> +
> +/**
> + * q6routing_stream_open() - Register a new stream for route setup
> + *
> + * @fedai_id: Frontend dai id.
> + * @perf_mode: Performance mode.
> + * @stream_id: ASM stream id to map.
> + * @stream_type: Direction of stream
> + *
> + * Return: Will be an negative on error or a zero on success.
> + */
> +int q6routing_stream_open(int fedai_id, int perf_mode,
> + int stream_id, int stream_type)
> +{
> + int j, topology, num_copps = 0;
> + struct route_payload payload;
> + int copp_idx;
> + struct session_data *session, *pdata;
> +
> + if (!routing_data) {
> + pr_err("Routing driver not yet ready\n");
> + return -EINVAL;
> + }
> +
> + session = &routing_data->sessions[stream_id - 1];
> + pdata = &routing_data->port_data[session->port_id];
> +
> + mutex_lock(&routing_data->lock);
> + session->fedai_id = fedai_id;
> +
> + session->path_type = pdata->path_type;
> + session->sample_rate = pdata->sample_rate;
> + session->channels = pdata->channels;
> + session->bits_per_sample = pdata->bits_per_sample;
> +
> + payload.num_copps = 0; /* only RX needs to use payload */
> + topology = NULL_COPP_TOPOLOGY;
> + copp_idx = q6adm_open(routing_data->dev, session->port_id,
> + session->path_type, session->sample_rate,
> + session->channels, topology, perf_mode,
> + session->bits_per_sample, 0, 0);
> +
> + if (copp_idx < 0) {
> + mutex_unlock(&routing_data->lock);
> + return -EINVAL;
> + }
> +
> + set_bit(copp_idx, &session->copp_map);
> +
> + for_each_set_bit(j, &session->copp_map, MAX_COPPS_PER_PORT) {
> + payload.port_id[num_copps] = session->port_id;
> + payload.copp_idx[num_copps] = j;
> + num_copps++;
> + }
> +
> + if (num_copps) {
> + payload.num_copps = num_copps;
> + payload.session_id = stream_id;
> + q6adm_matrix_map(routing_data->dev, session->path_type,
> + payload, perf_mode);
> + }
> + mutex_unlock(&routing_data->lock);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(q6routing_stream_open);
> +
> +static struct session_data *get_session_from_id(struct msm_routing_data *data,
> + int fedai_id)
> +{
> + int i;
> +
> + for (i = 0; i < MAX_SESSIONS; i++) {
> + if (fedai_id == data->sessions[i].fedai_id)
> + return &data->sessions[i];
> + }
> +
> + return NULL;
> +}
> +/**
> + * q6routing_stream_close() - Deregister a stream
> + *
> + * @fedai_id: Frontend dai id.
> + * @stream_type: Direction of stream
> + *
> + * Return: Will be an negative on error or a zero on success.
> + */
> +void q6routing_stream_close(int fedai_id, int stream_type)
> +{
> + struct session_data *session;
> + int idx;
> +
> + session = get_session_from_id(routing_data, fedai_id);
> + if (!session)
> + return;
> +
> + for_each_set_bit(idx, &session->copp_map, MAX_COPPS_PER_PORT)
> + q6adm_close(routing_data->dev, session->port_id,
> + session->perf_mode, idx);
> +
> + session->fedai_id = -1;
> + session->copp_map = 0;
> +}
> +EXPORT_SYMBOL_GPL(q6routing_stream_close);
> +
> +static int msm_routing_get_audio_mixer(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + struct snd_soc_dapm_context *dapm =
> + snd_soc_dapm_kcontrol_dapm(kcontrol);
> + struct soc_mixer_control *mc =
> + (struct soc_mixer_control *)kcontrol->private_value;
> + int session_id = mc->shift;
> + struct snd_soc_component *c = snd_soc_dapm_to_component(dapm);
> + struct msm_routing_data *priv = dev_get_drvdata(c->dev);
> + struct session_data *session = &priv->sessions[session_id];
> +
> + if (session->port_id == mc->reg)
> + ucontrol->value.integer.value[0] = 1;
> + else
> + ucontrol->value.integer.value[0] = 0;
> +
> + return 0;
> +}
> +
> +static int msm_routing_put_audio_mixer(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + struct snd_soc_dapm_context *dapm =
> + snd_soc_dapm_kcontrol_dapm(kcontrol);
> + struct snd_soc_component *c = snd_soc_dapm_to_component(dapm);
> + struct msm_routing_data *data = dev_get_drvdata(c->dev);
> + struct soc_mixer_control *mc =
> + (struct soc_mixer_control *)kcontrol->private_value;
> + struct snd_soc_dapm_update *update = NULL;
> + int be_id = mc->reg;
> + int session_id = mc->shift;
> + struct session_data *session = &data->sessions[session_id];
> +
> + if (ucontrol->value.integer.value[0]) {
> + session->port_id = be_id;
> + snd_soc_dapm_mixer_update_power(dapm, kcontrol, 1, update);
> + } else {
> + session->port_id = -1;
> + snd_soc_dapm_mixer_update_power(dapm, kcontrol, 0, update);
> + }
> +
> + return 1;
> +}
> +
> +static const struct snd_kcontrol_new hdmi_mixer_controls[] = {
> + SOC_SINGLE_EXT("MultiMedia1", HDMI_RX,
> + MSM_FRONTEND_DAI_MULTIMEDIA1, 1, 0,
At some point in future, when FE DAI IDs become more than "31",
SOC_DOUBLE_EXT would need to be used with "reg" marked with SND_SOC_NOPM
and FE DAI and BE DAI IDs passed in shift_left and shift_right. This is
to avoid having any "shift" operation issue in DAPM code, when reg is
not marked with SND_SOC_NOPM, and shift value is more than 31.
However, for now, its OK.
Acked-by: Banajit Goswami <bgoswami@codeaurora.org
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v6 12/15] KVM: arm64: Remove eager host SVE state saving
From: Marc Zyngier @ 2018-05-09 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525797900-5548-13-git-send-email-Dave.Martin@arm.com>
On 08/05/18 17:44, Dave Martin wrote:
> Now that the host SVE context can be saved on demand from Hyp,
> there is no longer any need to save this state in advance before
> entering the guest.
>
> This patch removes the relevant call to
> kvm_fpsimd_flush_cpu_state().
>
> Since the problem that function was intended to solve now no longer
> exists, the function and its dependencies are also deleted.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Acked-by: Christoffer Dall <christoffer.dall@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v7 22/24] ASoC: qdsp6: dt-bindings: Add apq8096 machine bindings
From: Banajit Goswami @ 2018-05-09 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501120820.11016-23-srinivas.kandagatla@linaro.org>
On 5/1/2018 5:08 AM, Srinivas Kandagatla wrote:
> Add devicetree bindings documentation file for Qualcomm apq8096 sound card.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/sound/qcom,apq8096.txt | 109 +++++++++++++++++++++
> 1 file changed, 109 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/qcom,apq8096.txt
>
Reviewed-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v6 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set
From: Russell King - ARM Linux @ 2018-05-09 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509050628.csbusplowpvmmiwa@pengutronix.de>
On Wed, May 09, 2018 at 07:06:28AM +0200, Oleksij Rempel wrote:
> On Tue, May 08, 2018 at 01:40:33PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Mar 05, 2018 at 11:25:19AM +0100, Oleksij Rempel wrote:
> > > One of the Freescale recommended sequences for power off with external
> > > PMIC is the following:
> > > ...
> > > 3. SoC is programming PMIC for power off when standby is asserted.
> > > 4. In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies.
> > >
> > > See:
> > > http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6DQRM.pdf
> > > page 5083
> > >
> > > This patch implements step 4. of this sequence.
> > >
> > > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> > > ---
> > > arch/arm/mach-imx/pm-imx6.c | 25 +++++++++++++++++++++++++
> > > 1 file changed, 25 insertions(+)
> > >
> > > diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
> > > index ecdf071653d4..24689260a2a5 100644
> > > --- a/arch/arm/mach-imx/pm-imx6.c
> > > +++ b/arch/arm/mach-imx/pm-imx6.c
> > > @@ -604,6 +604,28 @@ static void __init imx6_pm_common_init(const struct imx6_pm_socdata
> > > IMX6Q_GPR1_GINT);
> > > }
> > >
> > > +static void imx6_pm_stby_poweroff(void)
> > > +{
> > > + imx6_set_lpm(STOP_POWER_OFF);
> > > + cpu_suspend(0, imx6q_suspend_finish);
> >
> > Do you actually need to save the processor state etc here - the request
> > is after all to power down the system and not to suspend. Would calling
> > imx6q_suspend_finish() directly work (and hence simplify the code) ?
>
> yes you right. This will work as well.
> I'll send changed version after Rafaels feedback for kernel/reboot.c
> part.
> Russell, can I expect your Signed-off-by for changed patch?
No, please read Documentation/process/submitting-patches.rst section 12.
s-o-b does not apply in this case.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v6 14/15] KVM: arm64: Fold redundant exit code checks out of fixup_guest_exit()
From: Marc Zyngier @ 2018-05-09 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525797900-5548-15-git-send-email-Dave.Martin@arm.com>
On 08/05/18 17:44, Dave Martin wrote:
> The entire tail of fixup_guest_exit() is contained in if statements
> of the form if (x && *exit_code == ARM_EXCEPTION_TRAP). As a result,
> we can check just once and bail out of the function early, allowing
> the remaining if conditions to be simplified.
>
> The only awkward case is where *exit_code is changed to
> ARM_EXCEPTION_EL1_SERROR in the case of an illegal GICv2 CPU
> interface access: in that case, the GICv3 trap handling code is
> skipped using a goto. This avoids pointlessly evaluating the
> static branch check for the GICv3 case, even though we can't have
> vgic_v2_cpuif_trap and vgic_v3_cpuif_trap true simultaneously
> unless we have a GICv3 and GICv2 on the host: that sounds stupid,
> but I haven't satisfied myself that it can't happen.
>
> No functional change.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v6 01/15] thread_info: Add update_thread_flag() helpers
From: Marc Zyngier @ 2018-05-09 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525797900-5548-2-git-send-email-Dave.Martin@arm.com>
On 08/05/18 17:44, Dave Martin wrote:
> There are a number of bits of code sprinkled around the kernel to
> set a thread flag if a certain condition is true, and clear it
> otherwise.
>
> To help make those call sites terser and less cumbersome, this
> patch adds a new family of thread flag manipulators
>
> update*_thread_flag([...,] flag, cond)
>
> which do the equivalent of:
>
> if (cond)
> set*_thread_flag([...,] flag);
> else
> clear*_thread_flag([...,] flag);
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Oleg Nesterov <oleg@redhat.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v6 02/15] arm64: Use update{,_tsk}_thread_flag()
From: Marc Zyngier @ 2018-05-09 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525797900-5548-3-git-send-email-Dave.Martin@arm.com>
On 08/05/18 17:44, Dave Martin wrote:
> This patch uses the new update_thread_flag() helpers to simplify a
> couple of if () set; else clear; constructs.
>
> No functional change.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Applied "ASoC: fix return value check in mt6351_codec_driver_probe()" to the asoc tree
From: Mark Brown @ 2018-05-09 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525657185-73163-1-git-send-email-weiyongjun1@huawei.com>
The patch
ASoC: fix return value check in mt6351_codec_driver_probe()
has been applied to the asoc tree at
https://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 aaa730ca3f88f535dc12e2f0ff575f70f516841b Mon Sep 17 00:00:00 2001
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Mon, 7 May 2018 01:39:45 +0000
Subject: [PATCH] ASoC: fix return value check in mt6351_codec_driver_probe()
In case of error, the function dev_get_regmap() returns NULL pointer not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/codecs/mt6351.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/mt6351.c b/sound/soc/codecs/mt6351.c
index e739f078fec5..f73dcd753584 100644
--- a/sound/soc/codecs/mt6351.c
+++ b/sound/soc/codecs/mt6351.c
@@ -1472,8 +1472,8 @@ static int mt6351_codec_driver_probe(struct platform_device *pdev)
priv->dev = &pdev->dev;
priv->regmap = dev_get_regmap(pdev->dev.parent, NULL);
- if (IS_ERR(priv->regmap))
- return PTR_ERR(priv->regmap);
+ if (!priv->regmap)
+ return -ENODEV;
dev_dbg(priv->dev, "%s(), dev name %s\n",
__func__, dev_name(&pdev->dev));
--
2.17.0
^ permalink raw reply related
* [PATCH 2/5] pinctrl: Add STMFX GPIO expander Pinctrl/GPIO driver
From: Amelie DELAUNAY @ 2018-05-09 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb-=QU74-MZxMdB6QPqMLZr97WxN80iyOoTFqXPicL75w@mail.gmail.com>
On 04/26/2018 02:48 PM, Linus Walleij wrote:
> On Wed, Apr 11, 2018 at 11:47 AM, Amelie Delaunay
> <amelie.delaunay@st.com> wrote:
>
> Hi Amelie, thanks for your patch!
>
Hi Linus, thanks for reviewing!
>> This patch adds pinctrl/GPIO driver for STMicroelectronics
>> Multi-Function eXpander (STMFX) GPIO expander.
>> STMFX is an I2C slave controller, offering up to 24 GPIOs.
>> The driver relies on generic pin config interface to configure the GPIOs.
>>
>> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
>
> This is looking very good.
>
> The overall architecture of this patch set is excellent.
>
> I have only one major question about whether this should be
> a MFD parent and GPIO-pinctrl-child split driver, see below.
>
>> +config PINCTRL_STMFX
>> + tristate "STMicroelectronics STMFX I2C GPIO expander pinctrl driver"
>> + depends on GPIOLIB && I2C=y
>> + select GENERIC_PINCONF
>> + select GPIOLIB_IRQCHIP
>> + select REGMAP_I2C
>
> Thanks for using all the helpers, it makes the code very small and
> consistent and easy to review and maintain.
>
>> +#include <linux/bitfield.h>
>> +#include <linux/gpio.h>
>
> Please just use:
> #include <linux/gpio/driver.h>
>
OK, I'll fix it.
>> +static void stmfx_gpio_irq_toggle_trigger(struct stmfx_pinctrl *pctl,
>> + unsigned int offset)
>> +{
>> + u32 reg = get_reg(offset);
>> + u32 mask = get_mask(offset);
>> + int val;
>> +
>> + if (!(pctl->irq_toggle_edge[reg] & mask))
>> + return;
>> +
>> + val = stmfx_gpio_get(&pctl->gpio_chip, offset);
>> + if (val < 0)
>> + return;
>> +
>> + if (val) {
>> + pctl->irq_gpi_type[reg] &= mask;
>> + regmap_write_bits(pctl->regmap, STMFX_REG_IRQ_GPI_TYPE + reg,
>> + get_mask(offset), 0);
>> +
>> + } else {
>> + pctl->irq_gpi_type[reg] |= mask;
>> + regmap_write_bits(pctl->regmap, STMFX_REG_IRQ_GPI_TYPE + reg,
>> + get_mask(offset), get_mask(offset));
>> + }
>> +}
>
> We had a bit of discussion about edge trigger emulation on the
> mailing list. Strange that these HW engineers didn't think of this,
> I thought it was widely known that double-edge trigger (not just one
> or the other) is needed in contemporary GPIO HW.
>
Yes! Supported by the STM32L152 on which stmfx is based but not by the
FW abstraction. So, maybe, in a future stmfx FW version...
>> + if (!of_find_property(np, "gpio-ranges", NULL)) {
>> + ret = gpiochip_add_pin_range(&pctl->gpio_chip,
>> + dev_name(pctl->dev),
>> + 0, 0, pctl->pctl_desc.npins);
>> + if (ret)
>> + return ret;
>
> Do you really need to support DTBs without gpio-ranges?
>
> I.e. can't you just print an error and exit if there is no range?
>
> I think other drivers has this handling because of older
> DT bindings and trees drifting around.
>
You're right, no need to support DTBs without gpio-ranges. I'll add
gpio-ranges property under required section of stmfx bindings.
>> +static const struct regmap_config stmfx_regmap_config = {
>> + .reg_bits = 8,
>> + .val_bits = 8,
>> +};
>
> This can probably be improved in the future.
> Or are there really exactly 255 registers?
>
OK, I'll have a look to improve it.
>> +static int stmfx_probe(struct i2c_client *client,
>> + const struct i2c_device_id *id)
>> +{
>> + struct device_node *np = client->dev.of_node, *child;
>> + struct stmfx *stmfx;
>> + int ret;
>> +
>> + stmfx = devm_kzalloc(&client->dev, sizeof(*stmfx), GFP_KERNEL);
>> + if (!stmfx)
>> + return -ENOMEM;
>> +
>> + i2c_set_clientdata(client, stmfx);
>> +
>> + stmfx->dev = &client->dev;
>> +
>> + stmfx->regmap = devm_regmap_init_i2c(client, &stmfx_regmap_config);
>> + if (IS_ERR(stmfx->regmap)) {
>> + ret = PTR_ERR(stmfx->regmap);
>> + dev_err(stmfx->dev,
>> + "Failed to allocate register map: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ret = stmfx_chip_init(stmfx, client);
>> + if (ret) {
>> + if (ret == -ETIMEDOUT)
>> + return -EPROBE_DEFER;
>> + return ret;
>> + }
>> +
>> + stmfx->irq = client->irq;
>> + ret = stmfx_irq_init(stmfx);
>> + if (ret)
>> + return ret;
>> +
>> + for_each_available_child_of_node(np, child) {
>> + if (of_property_read_bool(child, "gpio-controller")) {
>> + ret = stmfx_gpio_init(stmfx, child);
>> + if (ret)
>> + goto err;
>> + }
>> + }
>
> Hm so you do not use a MFD driver for the core of the driver?
>
> Instead this driver becomes the core driver?
>
> I guess it is fine as long as the chip is only doing GPIO
> and pin control. If the chip has more abilities (such as PWM,
> LED...) then the core should be an MFD driver that spawns
> GPIO/pinctrl driver as a child, then this child looks up the
> regmap from the parent MFD driver.
Yes, this resumes the binding patch concerns.
stmfx chip on boards supported by Linux is only doing GPIO and pin
control. The other abilities (IDD measurement and TouchScreen
controller) are not used and cannot be tested with Linux for the time
being. But if these function are used, then the core part of this driver
(all not stmfx_gpio_/stmfx_pinctrl_/stmfx_pinconf_ prefixed functions)
will become an MFD driver.
>
> See for example how the simple STw481x driver does things:
> drivers/mfd/stw481x.c
> drivers/regulator/stw481x-vmmc.c
>
> This MFD has no GPIO/pin control but it illustrates a simple
> parent/child instantiation with an MFD core driver.
>
> It has this DTS entry:
>
> stw4811 at 2d {
> compatible = "st,stw4811";
> reg = <0x2d>;
> vmmc_regulator: vmmc {
> compatible = "st,stw481x-vmmc";
> regulator-name = "VMMC";
> regulator-min-microvolt = <1800000>;
> regulator-max-microvolt = <3300000>;
> };
> };
>
> The MFD driver matches and spawns the VMMC child
> then that driver mathes to the vmmc node.
>
> Yours,
> Linus Walleij
>
Thanks,
Amelie
^ permalink raw reply
* [PATCH v7 23/24] ASoC: qcom: apq8096: Add db820c machine driver
From: Banajit Goswami @ 2018-05-09 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501120820.11016-24-srinivas.kandagatla@linaro.org>
On 5/1/2018 5:08 AM, Srinivas Kandagatla wrote:
> This patch adds support to DB820c machine driver.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> sound/soc/qcom/Kconfig | 9 ++
> sound/soc/qcom/Makefile | 2 +
> sound/soc/qcom/apq8096.c | 238 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 249 insertions(+)
> create mode 100644 sound/soc/qcom/apq8096.c
<snip>
> +
> +static int apq8096_sbc_parse_of(struct snd_soc_card *card)
> +{
> + struct device_node *np, *codec, *platform, *cpu, *node;
> + struct device *dev = card->dev;
> + struct snd_soc_dai_link *link;
> + int ret, num_links;
> +
> + ret = snd_soc_of_parse_card_name(card, "qcom,model");
> + if (ret) {
> + dev_err(dev, "Error parsing card name: %d\n", ret);
> + return ret;
> + }
> +
> + node = dev->of_node;
> +
> + /* DAPM routes */
> + if (of_property_read_bool(node, "qcom,audio-routing")) {
> + ret = snd_soc_of_parse_audio_routing(card,
> + "qcom,audio-routing");
> + if (ret)
> + return ret;
> + }
> +
> + /* Populate links */
> + num_links = of_get_child_count(node);
> +
> + /* Allocate the DAI link array */
> + card->dai_link = kcalloc(num_links, sizeof(*link), GFP_KERNEL);
> + if (!card->dai_link)
> + return -ENOMEM;
> +
> + card->num_links = num_links;
> + link = card->dai_link;
> +
> + for_each_child_of_node(node, np) {
> + cpu = of_get_child_by_name(np, "cpu");
> + platform = of_get_child_by_name(np, "platform");
> + codec = of_get_child_by_name(np, "codec");
> +
> + if (!cpu) {
> + dev_err(dev, "Can't find cpu DT node\n");
clean up missing to kfree(card->dai_link)?
> + return -EINVAL;
> + }
> +
> + link->cpu_of_node = of_parse_phandle(cpu, "sound-dai", 0);
> + if (!link->cpu_of_node) {
> + dev_err(card->dev, "error getting cpu phandle\n");
ditto
> + return -EINVAL;
> + }
> +
> + ret = snd_soc_of_get_dai_name(cpu, &link->cpu_dai_name);
> + if (ret) {
> + dev_err(card->dev, "error getting cpu dai name\n");
ditto
> + return ret;
> + }
> +
> + if (codec && platform) {
> + link->platform_of_node = of_parse_phandle(platform,
> + "sound-dai",
> + 0);
> + if (!link->platform_of_node) {
> + dev_err(card->dev, "platform dai not found\n");
ditto
> + return -EINVAL;
> + }
> +
> + ret = snd_soc_of_get_dai_link_codecs(dev, codec, link);
> + if (ret < 0) {
> + dev_err(card->dev, "codec dai not found\n");
ditto
> + return ret;
> + }
> + link->no_pcm = 1;
> + link->ignore_suspend = 1;
ignore_suspend will also need to be set for FE DAIs?
> + link->ignore_pmdown_time = 1;
> + link->be_hw_params_fixup = apq8096_be_hw_params_fixup;
> + } else {
> + link->platform_of_node = link->cpu_of_node;
> + link->codec_dai_name = "snd-soc-dummy-dai";
> + link->codec_name = "snd-soc-dummy";
> + link->dynamic = 1;
> + }
> +
> + ret = of_property_read_string(np, "link-name", &link->name);
> + if (ret) {
> + dev_err(card->dev, "error getting codec dai_link name\n");
clean up
> + return ret;
> + }
> +
> + link->dpcm_playback = 1;
> + link->dpcm_capture = 1;
> + link->stream_name = link->name;
> + link++;
> + }
> +
> + return ret;
> +}
> +
> +static int apq8096_bind(struct device *dev)
> +{
> + struct snd_soc_card *card;
> + int ret;
> +
> + card = kzalloc(sizeof(*card), GFP_KERNEL);
> + if (!card)
> + return -ENOMEM;
> +
> + component_bind_all(dev, card);
> + card->dev = dev;
> + ret = apq8096_sbc_parse_of(card);
> + if (ret) {
> + dev_err(dev, "Error parsing OF data\n");
> + component_unbind_all(dev, card);
> + return ret;
> + }
> +
> + return snd_soc_register_card(card);
> +}
> +
> +static void apq8096_unbind(struct device *dev)
> +{
> + struct snd_soc_card *card = dev_get_drvdata(dev);
> +
> + component_unbind_all(dev, card);
> + snd_soc_unregister_card(card);
Should sound card not be unregistered first, before calling
component_unbind_all()?
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v7 24/24] MAINTAINERS: Add myself as co-maintainer of qcom audio
From: Banajit Goswami @ 2018-05-09 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180501120820.11016-25-srinivas.kandagatla@linaro.org>
On 5/1/2018 5:08 AM, Srinivas Kandagatla wrote:
> Add myself as co-maintainer of qcom audio drivers
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4340b783ab80..527e2658cfe4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11531,6 +11531,7 @@ F: drivers/crypto/qat/
> QCOM AUDIO (ASoC) DRIVERS
> M: Patrick Lai <plai@codeaurora.org>
> M: Banajit Goswami <bgoswami@codeaurora.org>
> +M: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> L: alsa-devel at alsa-project.org (moderated for non-subscribers)
> S: Supported
> F: sound/soc/qcom/
Acked-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v6 07/15] KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing
From: Dave Martin @ 2018-05-09 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cd45aff8-66dd-b6bc-ada0-189b45e09d17@arm.com>
On Wed, May 09, 2018 at 09:24:36AM +0100, Marc Zyngier wrote:
> On 08/05/18 17:44, Dave Martin wrote:
> > This patch refactors KVM to align the host and guest FPSIMD
> > save/restore logic with each other for arm64. This reduces the
[...]
> > diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> > index 9699c13..6429eb6 100644
> > --- a/arch/arm64/include/asm/kvm_asm.h
> > +++ b/arch/arm64/include/asm/kvm_asm.h
> > @@ -33,6 +33,8 @@
> > /* vcpu_arch flags field values: */
> > #define KVM_ARM64_DEBUG_DIRTY_SHIFT 0
> > #define KVM_ARM64_DEBUG_DIRTY (1 << KVM_ARM64_DEBUG_DIRTY_SHIFT)
>
> At some point, we could remove KVM_ARM64_DEBUG_DIRTY_SHIFT as it is not
> used anymore (since 1ea66d27e7b0). Do not respin on this account though.
I wondered about this... I presume this was used from assembly once
upon a time.
Since I need to repost for something else anyway, shall I delete that
and move the defines to kvm_host.h? There's no longer an obvious reason
for them to be in a different header.
[...]
> > diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> > new file mode 100644
> > index 0000000..7059275
> > --- /dev/null
> > +++ b/arch/arm64/kvm/fpsimd.c
> > @@ -0,0 +1,111 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * arch/arm64/kvm/fpsimd.c: Guest/host FPSIMD context coordination helpers
> > + *
> > + * Copyright 2018 Arm Limited
> > + * Author: Dave Martin <Dave.Martin@arm.com>
> > + */
> > +#include <linux/bottom_half.h>
> > +#include <linux/sched.h>
> > +#include <linux/thread_info.h>
> > +#include <linux/kvm_host.h>
> > +#include <asm/kvm_asm.h>
> > +#include <asm/kvm_host.h>
> > +#include <asm/kvm_mmu.h>
> > +
> > +/*
> > + * Called on entry to KVM_RUN unless this vcpu previously ran at least
> > + * once and the most recent prior KVM_RUN for this vcpu was called from
> > + * the same task as current (highly likely).
> > + *
> > + * This is guaranteed to execute before kvm_arch_vcpu_load_fp(vcpu),
> > + * such that on entering hyp the relevant parts of current are already
> > + * mapped.
> > + */
> > +int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu)
> > +{
> > + int ret;
> > +
> > + struct thread_info *ti = ¤t->thread_info;
> > + struct user_fpsimd_state *fpsimd = ¤t->thread.uw.fpsimd_state;
> > +
> > + /*
> > + * Make sure the host task thread flags and fpsimd state are
> > + * visible to hyp:
> > + */
> > + ret = create_hyp_mappings(ti, ti + 1, PAGE_HYP);
> > + if (ret)
> > + goto error;
> > +
> > + ret = create_hyp_mappings(fpsimd, fpsimd + 1, PAGE_HYP);
> > + if (ret)
> > + goto error;
> > +
> > + vcpu->arch.host_thread_info = kern_hyp_va(ti);
> > + vcpu->arch.host_fpsimd_state = kern_hyp_va(fpsimd);
>
> Since we assign host_fpsimd_state here, and that "map" is guaranteed to
> execute before "load"...
>
> > +error:
> > + return ret;
> > +}
> > +
> > +/*
> > + * Prepare vcpu for saving the host's FPSIMD state and loading the guest's.
> > + * The actual loading is done by the FPSIMD access trap taken to hyp.
> > + *
> > + * Here, we just set the correct metadata to indicate that the FPSIMD
> > + * state in the cpu regs (if any) belongs to current, and where to write
> > + * it back to if/when a FPSIMD access trap is taken.
> > + *
> > + * TIF_SVE is backed up here, since it may get clobbered with guest state.
> > + * This flag is restored by kvm_arch_vcpu_put_fp(vcpu).
> > + */
> > +void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
> > +{
> > + BUG_ON(system_supports_sve());
> > + BUG_ON(!current->mm);
> > +
> > + vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED | KVM_ARM64_HOST_SVE_IN_USE);
> > + if (test_thread_flag(TIF_SVE))
> > + vcpu->arch.flags |= KVM_ARM64_HOST_SVE_IN_USE;
> > +
> > + vcpu->arch.host_fpsimd_state =
> > + kern_hyp_va(¤t->thread.uw.fpsimd_state);
>
> ... what is the purpose of this assignment? I don't think it is harmful
> in any way, but I'm just wondering if I'm missing in the actual flow.
The pointer will be NULLed by __hyp_switch_fpsimd() when loading the
guest state in, to indicate that there is no longer any host state to
save. Perhaps it would have been clearer to have a separate flag to
represent this change of state.
As things stand I think you're right: the assignments are redundant.
We certainly need the pointer to reflect the current task, which is
the motivation for doing it here -- but in fact we need to do it
more often, at every vcpu_load().
I think the most appropriate thing is to delete the assignment from
_map_fp().
The alternative would be to add a flag for the "no host state to save"
case, and fpsimd_host_state only in the pid_change hook.
[...]
> > +/*
> > + * Write back the vcpu FPSIMD regs if they are dirty, and invalidate the
> > + * cpu FPSIMD regs so that they can't be spuriously reused if this vcpu
> > + * disappears and another task or vcpu appears that recycles the same
> > + * struct fpsimd_state.
> > + */
> > +void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
> > +{
> > + local_bh_disable();
> > +
> > + if (vcpu->arch.flags & KVM_ARM64_FP_ENABLED) {
> > + fpsimd_save();
> > + fpsimd_flush_cpu_state();
> > + set_thread_flag(TIF_FOREIGN_FPSTATE);
> > + }
> > +
> > + update_thread_flag(TIF_SVE,
> > + vcpu->arch.flags & KVM_ARM64_HOST_SVE_IN_USE);
>
> Does this indicate anything about the validity of the SVE registers? Or
> is it for the sole purpose of userspace not having to trap to re-enable SVE?
This is the host task's "SVE registers exist" flag. It's essential to
restore this correctly before re-enabling preemption, because it
controls where the regs are saved/restored from:
current->thread.fpsimd_state, or the dynamically allocated buffer
current->thread.sve_state (TIF_SVE set indicates the latter).
TIF_FOREIGN_FPSTATE is orthogonal to this, and indicates whether the
regs are actually loaded in the hardware. Obviously they aren't if
we had loaded the guest's regs meanwhile.
[...]
> > diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> > index c0796c4..75c3b65 100644
> > --- a/arch/arm64/kvm/hyp/switch.c
> > +++ b/arch/arm64/kvm/hyp/switch.c
> > @@ -27,15 +27,16 @@
> > #include <asm/kvm_mmu.h>
> > #include <asm/fpsimd.h>
> > #include <asm/debug-monitors.h>
> > +#include <asm/thread_info.h>
> >
> > -static bool __hyp_text __fpsimd_enabled_nvhe(void)
> > +static bool __hyp_text update_fp_enabled(struct kvm_vcpu *vcpu)
> > {
> > - return !(read_sysreg(cptr_el2) & CPTR_EL2_TFP);
> > -}
> > + if (vcpu->arch.host_thread_info->flags & _TIF_FOREIGN_FPSTATE) {
> > + vcpu->arch.host_fpsimd_state = NULL;
> > + vcpu->arch.flags &= ~KVM_ARM64_FP_ENABLED;
> > + }
>
> I must confess I don't get this bit. If we started off with an invalid
> host state (which is how I interpret TIF_FOREIGN_FPSTATE), why didn't we
> simply zero the pointer at load time? The thread flag cannot change in
> the meantime, right? Or did I get that wrong?
The host kernel can take interrupts in the run loop while outside the
guest, causing this flag to get set. So we really do need to re-check
on each entry to the guest.
I can add a one-line comment documenting the purpose of this function,
which should help understanding here, something like:
/* Check whether the FP regs were dirtied while in the host-side run loop */
[...]
> It otherwise looks good, and I don't think the above nits are
> problematic on their own.
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Thanks.
I will probably address the nits since I need to fix another build break
issue with CONFIG_KVM=n. That will be a pretty trivial respin.
Happy to keep your Reviewed-by with the discussed changes?
Cheers
---Dave
^ permalink raw reply
* [RFC PATCH] driver core: make deferring probe forever optional
From: Mark Brown @ 2018-05-09 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507223438.GB14924@minitux>
On Mon, May 07, 2018 at 03:34:38PM -0700, Bjorn Andersson wrote:
> And is this really a problem that does not exists in the ACPI world?
Sort of, in that on ACPI systems all devices are expected to live in
glorious isolation and anything they need transparently configured by
the firmware with any information about clock speeds or whatever coming
from proprietary/device specific properties (though that's severely
frowned upon) or the apparently idiomatic technique of hardcoding based
on DMI data which has some scalability issues. This works great for
systems intended to work in the ACPI model but is not entirely
successful once you get outside of that.
Some of the embedded ACPI people have been importing bits of DT
wholesale into ACPI, for those bits obviously all the DT issues get
imported too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180509/63308370/attachment.sig>
^ 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