* [PATCH] KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs
From: Shameerali Kolothum Thodi @ 2016-12-01 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480584341-32340-2-git-send-email-marc.zyngier@arm.com>
Hi Marc,
> -----Original Message-----
> From: kvmarm-bounces at lists.cs.columbia.edu [mailto:kvmarm-
> bounces at lists.cs.columbia.edu] On Behalf Of Marc Zyngier
> Sent: Thursday, December 01, 2016 9:26 AM
> To: Paolo Bonzini; Radim Kr?m??
> Cc: Catalin Marinas; kvmarm at lists.cs.columbia.edu; linux-arm-
> kernel at lists.infradead.org; kvm at vger.kernel.org
> Subject: [PATCH] KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs
>
> When we inject a level triggerered interrupt (and unless it is backed
> by the physical distributor - timer style), we request a maintenance
> interrupt. Part of the processing for that interrupt is to feed to the
> rest of KVM (and to the eventfd subsystem) the information that the
> interrupt has been EOIed.
>
> But that notification only makes sense for SPIs, and not PPIs (such as
> the PMU interrupt). Skip over the notification if the interrupt is not
> an SPI.
Just to clarify my understanding, the maintenance interrupt is generated
for cases where there is no mapping of virt to phys interrupts
(ie, ICH_LR HW bit is not set). And I was under the impression that
kvm_notify_acked_irq will eventually deactivate the interrupt on distributor
for such cases. Its not clear to me how the deactivation is done
otherwise.
Could you please help me to understand this better.
Thanks,
Shameer
> Cc: stable at vger.kernel.org # 4.7+
> Fixes: 140b086dd197 ("KVM: arm/arm64: vgic-new: Add GICv2 world switch
> backend")
> Fixes: 59529f69f504 ("KVM: arm/arm64: vgic-new: Add GICv3 world switch
> backend")
> Reported-by: Catalin Marinas <catalin.marinas@arm.com>
> Tested-by: Catalin Marinas <catalin.marinas@arm.com>
> Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> virt/kvm/arm/vgic/vgic-v2.c | 6 ++++--
> virt/kvm/arm/vgic/vgic-v3.c | 6 ++++--
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
> index 0a063af..9bab867 100644
> --- a/virt/kvm/arm/vgic/vgic-v2.c
> +++ b/virt/kvm/arm/vgic/vgic-v2.c
> @@ -50,8 +50,10 @@ void vgic_v2_process_maintenance(struct kvm_vcpu
> *vcpu)
>
> WARN_ON(cpuif->vgic_lr[lr] & GICH_LR_STATE);
>
> - kvm_notify_acked_irq(vcpu->kvm, 0,
> - intid - VGIC_NR_PRIVATE_IRQS);
> + /* Only SPIs require notification */
> + if (vgic_valid_spi(vcpu->kvm, intid))
> + kvm_notify_acked_irq(vcpu->kvm, 0,
> + intid - VGIC_NR_PRIVATE_IRQS);
> }
> }
>
> diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
> index 9f0dae3..5c9f974 100644
> --- a/virt/kvm/arm/vgic/vgic-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-v3.c
> @@ -41,8 +41,10 @@ void vgic_v3_process_maintenance(struct kvm_vcpu
> *vcpu)
>
> WARN_ON(cpuif->vgic_lr[lr] & ICH_LR_STATE);
>
> - kvm_notify_acked_irq(vcpu->kvm, 0,
> - intid - VGIC_NR_PRIVATE_IRQS);
> + /* Only SPIs require notification */
> + if (vgic_valid_spi(vcpu->kvm, intid))
> + kvm_notify_acked_irq(vcpu->kvm, 0,
> + intid - VGIC_NR_PRIVATE_IRQS);
> }
>
> /*
> --
> 2.1.4
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Dave Martin @ 2016-12-01 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dbcd545f-1358-6a80-5a9f-3e4a3c93189a@redhat.com>
On Thu, Dec 01, 2016 at 10:21:03AM +0100, Florian Weimer wrote:
> On 11/30/2016 02:56 PM, Dave Martin wrote:
>
> >If we do have distinct "set process VL" and "set thread VL" interfaces,
> >then my view is that the former should fail if there are already
> >multiple threads, rather than just setting the VL of a single thread or
> >(worse) asynchronously changing the VL of threads other than the
> >caller...
>
> Yes, looks feasible to me.
OK, I'll try to hack up something along these lines.
> >>>I'm not familiar with resumable functions/executors -- are these in
> >>>the C++ standards yet (not that that would cause me to be familiar
> >>>with them... ;) Any implementation of coroutines (i.e.,
> >>>cooperative switching) is likely to fall under the "setcontext"
> >>>argument above.
> >>
> >>There are different ways to implement coroutines. Stack switching (like
> >>setcontext) is obviously impacted by non-uniform register sizes. But even
> >>the most conservative variant, rather similar to switch-based emulation you
> >>sometimes see in C coroutine implementations, might have trouble restoring
> >>the state if it just cannot restore the saved state due to register size
> >>reductions.
> >
> >Which is not a problem if the variably-sized state is not part of the
> >switched context?
>
> The VL value is implicitly thread-local data, and the encoded state may have
> an implicit dependency on it, although it does not contain vector registers
> as such.
This doesn't sound like an absolute requirement to me.
If we presume that the SVE registers never need to get saved or
restored, what stops the context data format being VL-independent?
The setcontext()/getcontext() implementation for example will not change
at all for SVE.
> >Because the SVE procedure call standard determines that the SVE
> >registers are caller-save,
>
> By the way, how is this implemented? Some of them overlap existing
> callee-saved registers.
Basically, all the *new* state is caller-save.
The Neon/FPSIMD regs V8-V15 are callee-save, so in the SVE view
Zn[bits 127:0] is callee-save for all n = 8..15.
> >they are not live at any external function
> >boundary -- so in cooperative switching it is useless to save/restore
> >this state unless the coroutine framework is defined to have a special
> >procedure call standard.
>
> It can use the standard calling convention, but it may have selected a
> particular implementation based on the VL value before suspension.
If the save/restore logic doesn't touch SVE, which would its
implementation be VL-dependent?
Cheers
---Dave
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Laurent Pinchart @ 2016-12-01 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201085520.tk2kdi33rn6fyld2@lukather>
On Thursday 01 Dec 2016 09:55:20 Maxime Ripard wrote:
> On Thu, Dec 01, 2016 at 01:33:30AM +0800, Icenowy Zheng wrote:
> >>> hdmi-out {
> >>> compatible = "hdmi-connector";
> >>> type = "a";
> >>> /* I2C bus and GPIO references are made up for the
> >>> example */ ddc-i2c-bus = <&i2c4>;
> >>> hpd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>
> >>
> >> the "hdmi-connector" is a big piece of software. It must handle a lot
> >> of more and more exotic connectors.
> >> So, I hope that you have written a "simple-hdmi-connector" which does
> >> nothing but setting the connector type.
> >> Where is it?
> >
> > I suddenly thought about something...
> >
> > If a DVI connector instead of a HDMI connector is soldered, how
> > should such a device tree be written?
>
> Use a dvi-connector instead :)
The HDMI encoder DT node doesn't (and certainly shouldn't) report what type of
connector is mounted on the board. Having a connector node in DT makes the
connector type available to the system, allowing the DRM driver to expose the
right connector type to userspace (it would be confusing for the user to
report DRM_MODE_CONNECTOR_HDMIA for a DVI connector).
> > How about solder a HDMI-to-VGA bridge on the board? (Maybe there
> > should be "dumb-hdmi-dvi-bridge" and "dumb-hdmi-vga-bridge"
> > drivers?)
>
> It probably wouldn't be dumb, but yeah, it would definitely be a
> bridge instead of the connector.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 0/2] Make arm64 headers self-contained
From: Marc Zyngier @ 2016-12-01 10:44 UTC (permalink / raw)
To: linux-arm-kernel
Wookey recently reported that the arm64 headers are not
self-contained, making it impossible to build external kernel modules
using DKMS and a distribution kernel-headers package. I do not condone
the use of out of tree modules, but there is no reason to be more
awkward than strictly necessary, and having standalone headers seems
to be a reasonable requirement.
The offenders are asm/opcodes.h, which drags its 32bit counterpart
despite only requiring a handful of macros, and a bunch of Xen files
that directly include their 32bit equivalent.
This series solves the issue in two ways:
- asm/opcodes.h is killed, and the few required macros moved added at
the required locations
- asm/xen/* are brutally copied oved. It'd be better if they were
placed in a common location (include/xen/ ?), but at least that
solves it for now
Patches on top of -rc6.
Marc Zyngier (2):
arm64: Get rid of asm/opcodes.h
arm64: xen: Split architecture-specific headers from 32bit ARM
arch/arm64/include/asm/opcodes.h | 5 --
arch/arm64/include/asm/sysreg.h | 16 ++--
arch/arm64/include/asm/xen/hypercall.h | 88 ++++++++++++++++++++-
arch/arm64/include/asm/xen/hypervisor.h | 40 +++++++++-
arch/arm64/include/asm/xen/interface.h | 86 +++++++++++++++++++-
arch/arm64/include/asm/xen/page-coherent.h | 99 ++++++++++++++++++++++-
arch/arm64/include/asm/xen/page.h | 123 ++++++++++++++++++++++++++++-
arch/arm64/kernel/armv8_deprecated.c | 5 +-
arch/arm64/kernel/insn.c | 1 -
9 files changed, 445 insertions(+), 18 deletions(-)
delete mode 100644 arch/arm64/include/asm/opcodes.h
--
2.1.4
^ permalink raw reply
* [PATCH 1/2] arm64: Get rid of asm/opcodes.h
From: Marc Zyngier @ 2016-12-01 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480589074-809-1-git-send-email-marc.zyngier@arm.com>
The opcodes.h drags in a lot of definition from the 32bit port, most
of which is not required at all. Clean things up a bit by moving
the bare minimum of what is required next to the actual users,
and drop the include file.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/include/asm/opcodes.h | 5 -----
arch/arm64/include/asm/sysreg.h | 16 ++++++++++------
arch/arm64/kernel/armv8_deprecated.c | 5 ++++-
arch/arm64/kernel/insn.c | 1 -
4 files changed, 14 insertions(+), 13 deletions(-)
delete mode 100644 arch/arm64/include/asm/opcodes.h
diff --git a/arch/arm64/include/asm/opcodes.h b/arch/arm64/include/asm/opcodes.h
deleted file mode 100644
index 123f45d..0000000
--- a/arch/arm64/include/asm/opcodes.h
+++ /dev/null
@@ -1,5 +0,0 @@
-#ifdef CONFIG_CPU_BIG_ENDIAN
-#define CONFIG_CPU_ENDIAN_BE8 CONFIG_CPU_BIG_ENDIAN
-#endif
-
-#include <../../arm/include/asm/opcodes.h>
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 6c80b36..9e16a18 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -22,8 +22,6 @@
#include <linux/stringify.h>
-#include <asm/opcodes.h>
-
/*
* ARMv8 ARM reserves the following encoding for system registers:
* (Ref: ARMv8 ARM, Section: "System instruction class encoding overview",
@@ -37,6 +35,12 @@
#define sys_reg(op0, op1, crn, crm, op2) \
((((op0)&3)<<19)|((op1)<<16)|((crn)<<12)|((crm)<<8)|((op2)<<5))
+#ifdef __ASSEMBLY__
+#define __emit_inst(x) .inst (x)
+#else
+#define __emit_inst(x) ".inst " __stringify((x)) "\n\t"
+#endif
+
#define SYS_MIDR_EL1 sys_reg(3, 0, 0, 0, 0)
#define SYS_MPIDR_EL1 sys_reg(3, 0, 0, 0, 5)
#define SYS_REVIDR_EL1 sys_reg(3, 0, 0, 0, 6)
@@ -81,10 +85,10 @@
#define REG_PSTATE_PAN_IMM sys_reg(0, 0, 4, 0, 4)
#define REG_PSTATE_UAO_IMM sys_reg(0, 0, 4, 0, 3)
-#define SET_PSTATE_PAN(x) __inst_arm(0xd5000000 | REG_PSTATE_PAN_IMM |\
- (!!x)<<8 | 0x1f)
-#define SET_PSTATE_UAO(x) __inst_arm(0xd5000000 | REG_PSTATE_UAO_IMM |\
- (!!x)<<8 | 0x1f)
+#define SET_PSTATE_PAN(x) __emit_inst(0xd5000000 | REG_PSTATE_PAN_IMM | \
+ (!!x)<<8 | 0x1f)
+#define SET_PSTATE_UAO(x) __emit_inst(0xd5000000 | REG_PSTATE_UAO_IMM | \
+ (!!x)<<8 | 0x1f)
/* Common SCTLR_ELx flags. */
#define SCTLR_ELx_EE (1 << 25)
diff --git a/arch/arm64/kernel/armv8_deprecated.c b/arch/arm64/kernel/armv8_deprecated.c
index b0988bb..567c397 100644
--- a/arch/arm64/kernel/armv8_deprecated.c
+++ b/arch/arm64/kernel/armv8_deprecated.c
@@ -17,7 +17,6 @@
#include <asm/alternative.h>
#include <asm/cpufeature.h>
#include <asm/insn.h>
-#include <asm/opcodes.h>
#include <asm/sysreg.h>
#include <asm/system_misc.h>
#include <asm/traps.h>
@@ -352,6 +351,10 @@ static int emulate_swpX(unsigned int address, unsigned int *data,
return res;
}
+#define ARM_OPCODE_CONDTEST_FAIL 0
+#define ARM_OPCODE_CONDTEST_PASS 1
+#define ARM_OPCODE_CONDTEST_UNCOND 2
+
#define ARM_OPCODE_CONDITION_UNCOND 0xf
static unsigned int __kprobes aarch32_check_condition(u32 opcode, u32 psr)
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 6f2ac4f..94b62c1 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -30,7 +30,6 @@
#include <asm/cacheflush.h>
#include <asm/debug-monitors.h>
#include <asm/fixmap.h>
-#include <asm/opcodes.h>
#include <asm/insn.h>
#define AARCH64_INSN_SF_BIT BIT(31)
--
2.1.4
^ permalink raw reply related
* [PATCH 2/2] arm64: xen: Split architecture-specific headers from 32bit ARM
From: Marc Zyngier @ 2016-12-01 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480589074-809-1-git-send-email-marc.zyngier@arm.com>
ARM and arm64 Xen ports share a number of headers, leading to
packaging issues when these headers needs to be exported, as it
breaks the reasonable requirement that an architecture port
is standalone.
Solve the issue by copying the 5 header files over the arch
barrier.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/include/asm/xen/hypercall.h | 88 ++++++++++++++++++++-
arch/arm64/include/asm/xen/hypervisor.h | 40 +++++++++-
arch/arm64/include/asm/xen/interface.h | 86 +++++++++++++++++++-
arch/arm64/include/asm/xen/page-coherent.h | 99 ++++++++++++++++++++++-
arch/arm64/include/asm/xen/page.h | 123 ++++++++++++++++++++++++++++-
5 files changed, 431 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/xen/hypercall.h b/arch/arm64/include/asm/xen/hypercall.h
index 74b0c42..9d874db 100644
--- a/arch/arm64/include/asm/xen/hypercall.h
+++ b/arch/arm64/include/asm/xen/hypercall.h
@@ -1 +1,87 @@
-#include <../../arm/include/asm/xen/hypercall.h>
+/******************************************************************************
+ * hypercall.h
+ *
+ * Linux-specific hypervisor handling.
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef _ASM_ARM_XEN_HYPERCALL_H
+#define _ASM_ARM_XEN_HYPERCALL_H
+
+#include <linux/bug.h>
+
+#include <xen/interface/xen.h>
+#include <xen/interface/sched.h>
+#include <xen/interface/platform.h>
+
+long privcmd_call(unsigned call, unsigned long a1,
+ unsigned long a2, unsigned long a3,
+ unsigned long a4, unsigned long a5);
+int HYPERVISOR_xen_version(int cmd, void *arg);
+int HYPERVISOR_console_io(int cmd, int count, char *str);
+int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count);
+int HYPERVISOR_sched_op(int cmd, void *arg);
+int HYPERVISOR_event_channel_op(int cmd, void *arg);
+unsigned long HYPERVISOR_hvm_op(int op, void *arg);
+int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
+int HYPERVISOR_physdev_op(int cmd, void *arg);
+int HYPERVISOR_vcpu_op(int cmd, int vcpuid, void *extra_args);
+int HYPERVISOR_tmem_op(void *arg);
+int HYPERVISOR_vm_assist(unsigned int cmd, unsigned int type);
+int HYPERVISOR_platform_op_raw(void *arg);
+static inline int HYPERVISOR_platform_op(struct xen_platform_op *op)
+{
+ op->interface_version = XENPF_INTERFACE_VERSION;
+ return HYPERVISOR_platform_op_raw(op);
+}
+int HYPERVISOR_multicall(struct multicall_entry *calls, uint32_t nr);
+
+static inline int
+HYPERVISOR_suspend(unsigned long start_info_mfn)
+{
+ struct sched_shutdown r = { .reason = SHUTDOWN_suspend };
+
+ /* start_info_mfn is unused on ARM */
+ return HYPERVISOR_sched_op(SCHEDOP_shutdown, &r);
+}
+
+static inline void
+MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
+ unsigned int new_val, unsigned long flags)
+{
+ BUG();
+}
+
+static inline void
+MULTI_mmu_update(struct multicall_entry *mcl, struct mmu_update *req,
+ int count, int *success_count, domid_t domid)
+{
+ BUG();
+}
+
+#endif /* _ASM_ARM_XEN_HYPERCALL_H */
diff --git a/arch/arm64/include/asm/xen/hypervisor.h b/arch/arm64/include/asm/xen/hypervisor.h
index f263da8..9525151 100644
--- a/arch/arm64/include/asm/xen/hypervisor.h
+++ b/arch/arm64/include/asm/xen/hypervisor.h
@@ -1 +1,39 @@
-#include <../../arm/include/asm/xen/hypervisor.h>
+#ifndef _ASM_ARM_XEN_HYPERVISOR_H
+#define _ASM_ARM_XEN_HYPERVISOR_H
+
+#include <linux/init.h>
+
+extern struct shared_info *HYPERVISOR_shared_info;
+extern struct start_info *xen_start_info;
+
+/* Lazy mode for batching updates / context switch */
+enum paravirt_lazy_mode {
+ PARAVIRT_LAZY_NONE,
+ PARAVIRT_LAZY_MMU,
+ PARAVIRT_LAZY_CPU,
+};
+
+static inline enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
+{
+ return PARAVIRT_LAZY_NONE;
+}
+
+extern struct dma_map_ops *xen_dma_ops;
+
+#ifdef CONFIG_XEN
+void __init xen_early_init(void);
+#else
+static inline void xen_early_init(void) { return; }
+#endif
+
+#ifdef CONFIG_HOTPLUG_CPU
+static inline void xen_arch_register_cpu(int num)
+{
+}
+
+static inline void xen_arch_unregister_cpu(int num)
+{
+}
+#endif
+
+#endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/arm64/include/asm/xen/interface.h b/arch/arm64/include/asm/xen/interface.h
index 44457ae..75d5968 100644
--- a/arch/arm64/include/asm/xen/interface.h
+++ b/arch/arm64/include/asm/xen/interface.h
@@ -1 +1,85 @@
-#include <../../arm/include/asm/xen/interface.h>
+/******************************************************************************
+ * Guest OS interface to ARM Xen.
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
+ */
+
+#ifndef _ASM_ARM_XEN_INTERFACE_H
+#define _ASM_ARM_XEN_INTERFACE_H
+
+#include <linux/types.h>
+
+#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
+
+#define __DEFINE_GUEST_HANDLE(name, type) \
+ typedef struct { union { type *p; uint64_aligned_t q; }; } \
+ __guest_handle_ ## name
+
+#define DEFINE_GUEST_HANDLE_STRUCT(name) \
+ __DEFINE_GUEST_HANDLE(name, struct name)
+#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
+#define GUEST_HANDLE(name) __guest_handle_ ## name
+
+#define set_xen_guest_handle(hnd, val) \
+ do { \
+ if (sizeof(hnd) == 8) \
+ *(uint64_t *)&(hnd) = 0; \
+ (hnd).p = val; \
+ } while (0)
+
+#define __HYPERVISOR_platform_op_raw __HYPERVISOR_platform_op
+
+#ifndef __ASSEMBLY__
+/* Explicitly size integers that represent pfns in the interface with
+ * Xen so that we can have one ABI that works for 32 and 64 bit guests.
+ * Note that this means that the xen_pfn_t type may be capable of
+ * representing pfn's which the guest cannot represent in its own pfn
+ * type. However since pfn space is controlled by the guest this is
+ * fine since it simply wouldn't be able to create any sure pfns in
+ * the first place.
+ */
+typedef uint64_t xen_pfn_t;
+#define PRI_xen_pfn "llx"
+typedef uint64_t xen_ulong_t;
+#define PRI_xen_ulong "llx"
+typedef int64_t xen_long_t;
+#define PRI_xen_long "llx"
+/* Guest handles for primitive C types. */
+__DEFINE_GUEST_HANDLE(uchar, unsigned char);
+__DEFINE_GUEST_HANDLE(uint, unsigned int);
+DEFINE_GUEST_HANDLE(char);
+DEFINE_GUEST_HANDLE(int);
+DEFINE_GUEST_HANDLE(void);
+DEFINE_GUEST_HANDLE(uint64_t);
+DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(xen_pfn_t);
+DEFINE_GUEST_HANDLE(xen_ulong_t);
+
+/* Maximum number of virtual CPUs in multi-processor guests. */
+#define MAX_VIRT_CPUS 1
+
+struct arch_vcpu_info { };
+struct arch_shared_info { };
+
+/* TODO: Move pvclock definitions some place arch independent */
+struct pvclock_vcpu_time_info {
+ u32 version;
+ u32 pad0;
+ u64 tsc_timestamp;
+ u64 system_time;
+ u32 tsc_to_system_mul;
+ s8 tsc_shift;
+ u8 flags;
+ u8 pad[2];
+} __attribute__((__packed__)); /* 32 bytes */
+
+/* It is OK to have a 12 bytes struct with no padding because it is packed */
+struct pvclock_wall_clock {
+ u32 version;
+ u32 sec;
+ u32 nsec;
+ u32 sec_hi;
+} __attribute__((__packed__));
+#endif
+
+#endif /* _ASM_ARM_XEN_INTERFACE_H */
diff --git a/arch/arm64/include/asm/xen/page-coherent.h b/arch/arm64/include/asm/xen/page-coherent.h
index 2052102..95ce6ac 100644
--- a/arch/arm64/include/asm/xen/page-coherent.h
+++ b/arch/arm64/include/asm/xen/page-coherent.h
@@ -1 +1,98 @@
-#include <../../arm/include/asm/xen/page-coherent.h>
+#ifndef _ASM_ARM_XEN_PAGE_COHERENT_H
+#define _ASM_ARM_XEN_PAGE_COHERENT_H
+
+#include <asm/page.h>
+#include <linux/dma-mapping.h>
+
+void __xen_dma_map_page(struct device *hwdev, struct page *page,
+ dma_addr_t dev_addr, unsigned long offset, size_t size,
+ enum dma_data_direction dir, unsigned long attrs);
+void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs);
+void __xen_dma_sync_single_for_cpu(struct device *hwdev,
+ dma_addr_t handle, size_t size, enum dma_data_direction dir);
+
+void __xen_dma_sync_single_for_device(struct device *hwdev,
+ dma_addr_t handle, size_t size, enum dma_data_direction dir);
+
+static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
+{
+ return __generic_dma_ops(hwdev)->alloc(hwdev, size, dma_handle, flags, attrs);
+}
+
+static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
+ void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
+{
+ __generic_dma_ops(hwdev)->free(hwdev, size, cpu_addr, dma_handle, attrs);
+}
+
+static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
+ dma_addr_t dev_addr, unsigned long offset, size_t size,
+ enum dma_data_direction dir, unsigned long attrs)
+{
+ unsigned long page_pfn = page_to_xen_pfn(page);
+ unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
+ unsigned long compound_pages =
+ (1<<compound_order(page)) * XEN_PFN_PER_PAGE;
+ bool local = (page_pfn <= dev_pfn) &&
+ (dev_pfn - page_pfn < compound_pages);
+
+ /*
+ * Dom0 is mapped 1:1, while the Linux page can span across
+ * multiple Xen pages, it's not possible for it to contain a
+ * mix of local and foreign Xen pages. So if the first xen_pfn
+ * == mfn the page is local otherwise it's a foreign page
+ * grant-mapped in dom0. If the page is local we can safely
+ * call the native dma_ops function, otherwise we call the xen
+ * specific function.
+ */
+ if (local)
+ __generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
+ else
+ __xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir, attrs);
+}
+
+static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ unsigned long pfn = PFN_DOWN(handle);
+ /*
+ * Dom0 is mapped 1:1, while the Linux page can be spanned accross
+ * multiple Xen page, it's not possible to have a mix of local and
+ * foreign Xen page. Dom0 is mapped 1:1, so calling pfn_valid on a
+ * foreign mfn will always return false. If the page is local we can
+ * safely call the native dma_ops function, otherwise we call the xen
+ * specific function.
+ */
+ if (pfn_valid(pfn)) {
+ if (__generic_dma_ops(hwdev)->unmap_page)
+ __generic_dma_ops(hwdev)->unmap_page(hwdev, handle, size, dir, attrs);
+ } else
+ __xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
+}
+
+static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
+ dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+ unsigned long pfn = PFN_DOWN(handle);
+ if (pfn_valid(pfn)) {
+ if (__generic_dma_ops(hwdev)->sync_single_for_cpu)
+ __generic_dma_ops(hwdev)->sync_single_for_cpu(hwdev, handle, size, dir);
+ } else
+ __xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
+}
+
+static inline void xen_dma_sync_single_for_device(struct device *hwdev,
+ dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+ unsigned long pfn = PFN_DOWN(handle);
+ if (pfn_valid(pfn)) {
+ if (__generic_dma_ops(hwdev)->sync_single_for_device)
+ __generic_dma_ops(hwdev)->sync_single_for_device(hwdev, handle, size, dir);
+ } else
+ __xen_dma_sync_single_for_device(hwdev, handle, size, dir);
+}
+
+#endif /* _ASM_ARM_XEN_PAGE_COHERENT_H */
diff --git a/arch/arm64/include/asm/xen/page.h b/arch/arm64/include/asm/xen/page.h
index bed87ec..415dbc6 100644
--- a/arch/arm64/include/asm/xen/page.h
+++ b/arch/arm64/include/asm/xen/page.h
@@ -1 +1,122 @@
-#include <../../arm/include/asm/xen/page.h>
+#ifndef _ASM_ARM_XEN_PAGE_H
+#define _ASM_ARM_XEN_PAGE_H
+
+#include <asm/page.h>
+#include <asm/pgtable.h>
+
+#include <linux/pfn.h>
+#include <linux/types.h>
+#include <linux/dma-mapping.h>
+
+#include <xen/xen.h>
+#include <xen/interface/grant_table.h>
+
+#define phys_to_machine_mapping_valid(pfn) (1)
+
+/* Xen machine address */
+typedef struct xmaddr {
+ phys_addr_t maddr;
+} xmaddr_t;
+
+/* Xen pseudo-physical address */
+typedef struct xpaddr {
+ phys_addr_t paddr;
+} xpaddr_t;
+
+#define XMADDR(x) ((xmaddr_t) { .maddr = (x) })
+#define XPADDR(x) ((xpaddr_t) { .paddr = (x) })
+
+#define INVALID_P2M_ENTRY (~0UL)
+
+/*
+ * The pseudo-physical frame (pfn) used in all the helpers is always based
+ * on Xen page granularity (i.e 4KB).
+ *
+ * A Linux page may be split across multiple non-contiguous Xen page so we
+ * have to keep track with frame based on 4KB page granularity.
+ *
+ * PV drivers should never make a direct usage of those helpers (particularly
+ * pfn_to_gfn and gfn_to_pfn).
+ */
+
+unsigned long __pfn_to_mfn(unsigned long pfn);
+extern struct rb_root phys_to_mach;
+
+/* Pseudo-physical <-> Guest conversion */
+static inline unsigned long pfn_to_gfn(unsigned long pfn)
+{
+ return pfn;
+}
+
+static inline unsigned long gfn_to_pfn(unsigned long gfn)
+{
+ return gfn;
+}
+
+/* Pseudo-physical <-> BUS conversion */
+static inline unsigned long pfn_to_bfn(unsigned long pfn)
+{
+ unsigned long mfn;
+
+ if (phys_to_mach.rb_node != NULL) {
+ mfn = __pfn_to_mfn(pfn);
+ if (mfn != INVALID_P2M_ENTRY)
+ return mfn;
+ }
+
+ return pfn;
+}
+
+static inline unsigned long bfn_to_pfn(unsigned long bfn)
+{
+ return bfn;
+}
+
+#define bfn_to_local_pfn(bfn) bfn_to_pfn(bfn)
+
+/* VIRT <-> GUEST conversion */
+#define virt_to_gfn(v) (pfn_to_gfn(virt_to_phys(v) >> XEN_PAGE_SHIFT))
+#define gfn_to_virt(m) (__va(gfn_to_pfn(m) << XEN_PAGE_SHIFT))
+
+/* Only used in PV code. But ARM guests are always HVM. */
+static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
+{
+ BUG();
+}
+
+/* TODO: this shouldn't be here but it is because the frontend drivers
+ * are using it (its rolled in headers) even though we won't hit the code path.
+ * So for right now just punt with this.
+ */
+static inline pte_t *lookup_address(unsigned long address, unsigned int *level)
+{
+ BUG();
+ return NULL;
+}
+
+extern int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
+ struct gnttab_map_grant_ref *kmap_ops,
+ struct page **pages, unsigned int count);
+
+extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
+ struct gnttab_unmap_grant_ref *kunmap_ops,
+ struct page **pages, unsigned int count);
+
+bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
+bool __set_phys_to_machine_multi(unsigned long pfn, unsigned long mfn,
+ unsigned long nr_pages);
+
+static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
+{
+ return __set_phys_to_machine(pfn, mfn);
+}
+
+#define xen_remap(cookie, size) ioremap_cache((cookie), (size))
+#define xen_unmap(cookie) iounmap((cookie))
+
+bool xen_arch_need_swiotlb(struct device *dev,
+ phys_addr_t phys,
+ dma_addr_t dev_addr);
+unsigned long xen_get_swiotlb_free_pages(unsigned int order);
+
+#endif /* _ASM_ARM_XEN_PAGE_H */
--
2.1.4
^ permalink raw reply related
* [PATCH] dmaengine: at_xdmac: don't restore unsaved status
From: Alexandre Belloni @ 2016-12-01 10:49 UTC (permalink / raw)
To: linux-arm-kernel
save_gs is supposed to save the channel status in order to be restored at
resume time but it is never updated and is always 0. Anyway, the channel
status is updated in the per channel loop later in the resume function.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/dma/at_xdmac.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index b7d7f2d443a1..8c1abb794340 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -221,7 +221,6 @@ struct at_xdmac {
int irq;
struct clk *clk;
u32 save_gim;
- u32 save_gs;
struct dma_pool *at_xdmac_desc_pool;
struct at_xdmac_chan chan[0];
};
@@ -1896,7 +1895,6 @@ static int atmel_xdmac_resume(struct device *dev)
}
at_xdmac_write(atxdmac, AT_XDMAC_GIE, atxdmac->save_gim);
- at_xdmac_write(atxdmac, AT_XDMAC_GE, atxdmac->save_gs);
list_for_each_entry_safe(chan, _chan, &atxdmac->dma.channels, device_node) {
atchan = to_at_xdmac_chan(chan);
at_xdmac_chan_write(atchan, AT_XDMAC_CC, atchan->save_cc);
--
2.10.2
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: at91: add dma1 definition to sama5d2
From: Nicolas Ferre @ 2016-12-01 10:49 UTC (permalink / raw)
To: linux-arm-kernel
The sama5d2 SoC has a second DMA controller and can be used just like DMA0.
By default both DMA controllers are configured as "Secure" in
MATRIX_SPSELR so we can use whichever we want in a "single Secure World"
configuration.
Surprisingly the DMA1 has a lower address than DMA0. To avoid confusion
place it after DMA0 node anyway.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/sama5d2.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index ceb9783ff7e1..c791ce9c750c 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -395,6 +395,16 @@
clock-names = "dma_clk";
};
+ /* Place dma1 here despite its address */
+ dma1: dma-controller at f0004000 {
+ compatible = "atmel,sama5d4-dma";
+ reg = <0xf0004000 0x1000>;
+ interrupts = <7 IRQ_TYPE_LEVEL_HIGH 0>;
+ #dma-cells = <1>;
+ clocks = <&dma1_clk>;
+ clock-names = "dma_clk";
+ };
+
pmc: pmc at f0014000 {
compatible = "atmel,sama5d2-pmc", "syscon";
reg = <0xf0014000 0x160>;
--
2.9.0
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: at91: sama5d2: move UART3 to DMA1
From: Nicolas Ferre @ 2016-12-01 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201104949.23985-1-nicolas.ferre@atmel.com>
Now that DMA1 is defined, use it to distribute channel usage among the two
controllers.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/sama5d2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index c791ce9c750c..5b69eff523d9 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -1151,10 +1151,10 @@
compatible = "atmel,at91sam9260-usart";
reg = <0xfc008000 0x100>;
interrupts = <27 IRQ_TYPE_LEVEL_HIGH 7>;
- dmas = <&dma0
+ dmas = <&dma1
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
AT91_XDMAC_DT_PERID(41))>,
- <&dma0
+ <&dma1
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
AT91_XDMAC_DT_PERID(42))>;
dma-names = "tx", "rx";
--
2.9.0
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: at91: sama5d2 Xplained: use DMA for UART3
From: Nicolas Ferre @ 2016-12-01 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201104949.23985-1-nicolas.ferre@atmel.com>
Use DMA for UART3 as we have enough channels and to show how to
specify DMA use with serial nodes.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 0b9a59d5fdac..e2d5cb3fecb1 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -256,6 +256,8 @@
};
uart3: serial at fc008000 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart3_default>;
status = "okay";
--
2.9.0
^ permalink raw reply related
* [PATCH] KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs
From: Marc Zyngier @ 2016-12-01 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA817475F7E@lhreml504-mbs>
On 01/12/16 10:28, Shameerali Kolothum Thodi wrote:
> Hi Marc,
>
>> -----Original Message-----
>> From: kvmarm-bounces at lists.cs.columbia.edu [mailto:kvmarm-
>> bounces at lists.cs.columbia.edu] On Behalf Of Marc Zyngier
>> Sent: Thursday, December 01, 2016 9:26 AM
>> To: Paolo Bonzini; Radim Kr?m??
>> Cc: Catalin Marinas; kvmarm at lists.cs.columbia.edu; linux-arm-
>> kernel at lists.infradead.org; kvm at vger.kernel.org
>> Subject: [PATCH] KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs
>>
>> When we inject a level triggerered interrupt (and unless it is backed
>> by the physical distributor - timer style), we request a maintenance
>> interrupt. Part of the processing for that interrupt is to feed to the
>> rest of KVM (and to the eventfd subsystem) the information that the
>> interrupt has been EOIed.
>>
>> But that notification only makes sense for SPIs, and not PPIs (such as
>> the PMU interrupt). Skip over the notification if the interrupt is not
>> an SPI.
>
> Just to clarify my understanding, the maintenance interrupt is generated
> for cases where there is no mapping of virt to phys interrupts
> (ie, ICH_LR HW bit is not set). And I was under the impression that
> kvm_notify_acked_irq will eventually deactivate the interrupt on distributor
> for such cases. Its not clear to me how the deactivation is done
> otherwise.
>
> Could you please help me to understand this better.
kvm_notify_acked_irq() doesn't do *anything* at the distributor level,
ever (it has no idea of anything GIC-specific anyway). It's sole job is
to signal the rest of the stack that an interrupt has been EOIed in the
guest.
For these interrupts, which are purely virtual, there is absolutely
nothing to do at the physical distributor level anyway. Furthermore,
kvm_notify_acked_irq doesn't know about per-cpu interrupt, which is why
we cannot notify them.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2] mach-omap2: fixing wrong strcat for Non-NULL terminated string
From: Maninder Singh @ 2016-12-01 10:58 UTC (permalink / raw)
To: linux-arm-kernel
variable name can have Non NULL terminated string after cropping
which may result strcat to fail, and cropping is not
required if (strlen(oh->name) + 8 < MOD_CLK_MAX_NAME_LEN).
Issue caught with static analysis tool:
"Dangerous usage of 'name' (strncpy doesn't always 0-terminate it)"
Signed-off-by: Vaneet Narang <v.narang@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
---
v1 -> v2: changed strncpy to strlcpy
arch/arm/mach-omap2/omap_hwmod.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 759e1d4..582b95a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -742,12 +742,14 @@ static int _init_main_clk(struct omap_hwmod *oh)
char name[MOD_CLK_MAX_NAME_LEN];
struct clk *clk;
- /* +7 magic comes from '_mod_ck' suffix */
- if (strlen(oh->name) + 7 > MOD_CLK_MAX_NAME_LEN)
+ /* +8 magic comes from strlen("_mod_ck") added as suffix */
+ if (strlen(oh->name) + 8 > MOD_CLK_MAX_NAME_LEN) {
pr_warn("%s: warning: cropping name for %s\n", __func__,
oh->name);
+ strlcpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - 7);
+ } else
+ strcpy(name, oh->name);
- strncpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - 7);
strcat(name, "_mod_ck");
clk = clk_get(NULL, name);
--
1.9.1
^ permalink raw reply related
* [PATCH v7 0/4] Add basic support for the I2C units of the Armada 3700
From: Romain Perier @ 2016-12-01 11:04 UTC (permalink / raw)
To: linux-arm-kernel
This series add basic support for the I2C bus interface units present
in the Armada 3700 to the pxa-i2c driver. It also add the definitions of
the device nodes to the devicetree at the SoC level and for its official
development board: the Armada 3720 DB.
Romain Perier (4):
i2c: pxa: Add definition of fast and high speed modes via the regs
layout
i2c: pxa: Add support for the I2C units found in Armada 3700
arm64: dts: marvell: Add I2C definitions for the Armada 3700
dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 26 +++++++++++++++++++++--
5 files changed, 48 insertions(+), 3 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v7 1/4] i2c: pxa: Add definition of fast and high speed modes via the regs layout
From: Romain Perier @ 2016-12-01 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201110440.27530-1-romain.perier@free-electrons.com>
So far, the bit masks for the fast and high speed mode were statically
defined. Some IP blocks might use different bits for these modes.
This commit introduces new fields in order to enable the definition of
different bit masks for these features. If these fields are undefined,
ICR_FM and ICR_HS are selected to preserve backward compatibility with
other IPs.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Changes in v7:
- Fixed line over 80 characters for fm_mask and hs_mask in the probe
function.
drivers/i2c/busses/i2c-pxa.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index e28b825..b4ac235 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -48,6 +48,8 @@ struct pxa_reg_layout {
u32 isar;
u32 ilcr;
u32 iwcr;
+ u32 fm;
+ u32 hs;
};
enum pxa_i2c_types {
@@ -193,6 +195,8 @@ struct pxa_i2c {
unsigned char master_code;
unsigned long rate;
bool highmode_enter;
+ u32 fm_mask;
+ u32 hs_mask;
};
#define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -503,8 +507,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
writel(i2c->slave_addr, _ISAR(i2c));
/* set control register values */
- writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
- writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
+ writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
+ writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(&i2c->adap.dev, "Enabling slave mode\n");
@@ -1234,6 +1238,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
i2c->reg_idbr = i2c->reg_base + pxa_reg_layout[i2c_type].idbr;
i2c->reg_icr = i2c->reg_base + pxa_reg_layout[i2c_type].icr;
i2c->reg_isr = i2c->reg_base + pxa_reg_layout[i2c_type].isr;
+ i2c->fm_mask = pxa_reg_layout[i2c_type].fm ? : ICR_FM;
+ i2c->hs_mask = pxa_reg_layout[i2c_type].hs ? : ICR_HS;
+
if (i2c_type != REGS_CE4100)
i2c->reg_isar = i2c->reg_base + pxa_reg_layout[i2c_type].isar;
--
2.9.3
^ permalink raw reply related
* [PATCH v7 2/4] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-12-01 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201110440.27530-1-romain.perier@free-electrons.com>
The Armada 3700 has two I2C controllers that is compliant with the I2C
Bus Specificiation 2.1, supports multi-master and different bus speed:
Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
High speed mode (up to 3.4 Mhz).
This IP block has a lot of similarity with the PXA, except some register
offsets and bitfield. This commits adds a basic support for this I2C
unit.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
Changes in v6:
- Revert back A3700_REGS, as asked by Wolfram and define fm_mask
and hs_mask in the register layout. I moved the generic code
for fm_mask and hs_mask to a seperated commit (1/4)
Changes in v5:
- Don't define registers for armada-3700, we can re-use the ones
for PXA3XX.
- Define registers mask when OF is not used, in probe_pdata.
Changes in v4:
- Replaced the type of hs_mask and fm_mask by u32, instead of
unsigned int, As writel() take an u32 as first argument...
Changes in v3:
- Replaced the type of hs_mask and fm_mask by unsigned int,
instead of unsigned long.
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 15 +++++++++++++++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index d252276..2f56a26 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -763,7 +763,7 @@ config I2C_PUV3
config I2C_PXA
tristate "Intel PXA2XX I2C adapter"
- depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
+ depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
help
If you have devices in the PXA I2C bus, say yes to this option.
This driver can also be built as a module. If so, the module
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index b4ac235..6cf333e 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -57,8 +57,12 @@ enum pxa_i2c_types {
REGS_PXA3XX,
REGS_CE4100,
REGS_PXA910,
+ REGS_A3700,
};
+#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
+#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
+
/*
* I2C registers definitions
*/
@@ -93,6 +97,15 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
.ilcr = 0x28,
.iwcr = 0x30,
},
+ [REGS_A3700] = {
+ .ibmr = 0x00,
+ .idbr = 0x04,
+ .icr = 0x08,
+ .isr = 0x0c,
+ .isar = 0x10,
+ .fm = ICR_BUSMODE_FM,
+ .hs = ICR_BUSMODE_HS,
+ },
};
static const struct platform_device_id i2c_pxa_id_table[] = {
@@ -100,6 +113,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa3xx-pwri2c", REGS_PXA3XX },
{ "ce4100-i2c", REGS_CE4100 },
{ "pxa910-i2c", REGS_PXA910 },
+ { "armada-3700-i2c", REGS_A3700 },
{ },
};
MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -1141,6 +1155,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
{ .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
+ { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
{}
};
MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
--
2.9.3
^ permalink raw reply related
* [PATCH v7 3/4] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Romain Perier @ 2016-12-01 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201110440.27530-1-romain.perier@free-electrons.com>
The Armada 3700 has two i2c bus interface units, this commit adds the
definitions of the corresponding device nodes. It also enables the node
on the development board for this SoC.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6..16d84af 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -62,6 +62,10 @@
};
};
+&i2c0 {
+ status = "okay";
+};
+
/* CON3 */
&sata {
status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index e9bd587..1b0fd21 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -98,6 +98,24 @@
/* 32M internal register @ 0xd000_0000 */
ranges = <0x0 0x0 0xd0000000 0x2000000>;
+ i2c0: i2c at 11000 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11000 0x24>;
+ clocks = <&nb_periph_clk 10>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
+ i2c1: i2c at 11080 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11080 0x24>;
+ clocks = <&nb_periph_clk 9>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
uart0: serial at 12000 {
compatible = "marvell,armada-3700-uart";
reg = <0x12000 0x400>;
--
2.9.3
^ permalink raw reply related
* [PATCH v7 4/4] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-12-01 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201110440.27530-1-romain.perier@free-electrons.com>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v5:
- Added the tag 'Acked-by', by Rob Herring
Changes in v2:
- Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
and not "marvell,armada-3700".
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :
--
2.9.3
^ permalink raw reply related
* [PATCH v3 11/14] ACPI: irq: introduce interrupt producer
From: Aleksey Makarov @ 2016-12-01 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477408169-22217-12-git-send-email-guohanjun@huawei.com>
Hi Hanjun,
On 10/25/2016 09:09 PM, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> In ACPI 6.1 spec, section 19.6.62, Interrupt Resource Descriptor Macro,
[ ... ]
> ---
> drivers/acpi/gsi.c | 10 ++++--
> drivers/acpi/resource.c | 85 ++++++++++++++++++++++++++++++++++---------------
> include/acpi/acpi_bus.h | 1 +
> 3 files changed, 68 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/acpi/gsi.c b/drivers/acpi/gsi.c
> index ee9e0f2..29ee547 100644
> --- a/drivers/acpi/gsi.c
> +++ b/drivers/acpi/gsi.c
> @@ -55,13 +55,19 @@ int acpi_register_gsi(struct device *dev, u32 gsi, int trigger,
> int polarity)
> {
> struct irq_fwspec fwspec;
> + struct acpi_device *adev = dev ? to_acpi_device(dev) : NULL;
Why are you sure dev is always an acpi device?
Look for example at drivers/acpi/pci_irq.c:377 where this function
is called for a PCI device
>
> - if (WARN_ON(!acpi_gsi_domain_id)) {
> + if (adev && &adev->fwnode && adev->interrupt_producer)
&adev->fwnode is always true
> + /* devices in DSDT connecting to spefic interrupt producer */
> + fwspec.fwnode = adev->interrupt_producer;
> + else if (acpi_gsi_domain_id)
> + /* devices connecting to gicd in default */
> + fwspec.fwnode = acpi_gsi_domain_id;
> + else {
> pr_warn("GSI: No registered irqchip, giving up\n");
> return -EINVAL;
> }
[ ... ]
All the best
Aleksey Makarov
^ permalink raw reply
* [GIT PULL 1/6] Broadcom soc changes for 4.10
From: Rafał Miłecki @ 2016-12-01 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <23121827.vnVDrZQAeV@wuerfel>
On 2016-11-30 17:52, Arnd Bergmann wrote:
> On Monday, November 21, 2016 9:48:19 PM CET Florian Fainelli wrote:
>> This pull request contains Broadcom ARM-based SoC changes for 4.10,
>> please pull
>> the following:
>>
>> - Rafal adds back the abort handler hook on BCM5301x which is required
>> to silence
>> errors forwared from the PCIe controller that cannot be silenced at
>> the PCIe RC level
>>
>
> Pulled into next/soc.
>
> It's unclear to me whether we want this to be backported to stable
> kernels,
> can you clarify?
It took me/us so much time to get an agreement on this patch I totally
forgot
about backporting it to stable.
To be clear it indeed fixes a regression. Commit 937b12306ea79 ("ARM:
BCM5301X:
remove workaround imprecise abort fault handler") went into 4.5, so this
one
could be backported to 4.5+.
As this has been already pulled, I think I'll wait for it to appear in
Linus's
tree and just e-mail stable guys manually (unless someone objects).
Thanks for
bringing my attention to this.
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: used managed kasprintf
From: Nicolas Ferre @ 2016-12-01 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201102656.29041-1-alexandre.belloni@free-electrons.com>
Le 01/12/2016 ? 11:26, Alexandre Belloni a ?crit :
> Use devm_kasprintf instead of simple kasprintf to free the allocated memory
> when needed.
>
> Suggested-by: Peter Rosin <peda@axentia.se>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/usb/gadget/udc/atmel_usba_udc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index 45bc997d0711..aec72fe8273c 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -1978,7 +1978,8 @@ static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
> dev_err(&pdev->dev, "of_probe: name error(%d)\n", ret);
> goto err;
> }
> - ep->ep.name = kasprintf(GFP_KERNEL, "ep%d", ep->index);
> + ep->ep.name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "ep%d",
> + ep->index);
>
> ep->ep_regs = udc->regs + USBA_EPT_BASE(i);
> ep->dma_regs = udc->regs + USBA_DMA_BASE(i);
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] dmaengine: at_xdmac: don't restore unsaved status
From: Nicolas Ferre @ 2016-12-01 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201104903.30019-1-alexandre.belloni@free-electrons.com>
Le 01/12/2016 ? 11:49, Alexandre Belloni a ?crit :
> save_gs is supposed to save the channel status in order to be restored at
> resume time but it is never updated and is always 0. Anyway, the channel
> status is updated in the per channel loop later in the resume function.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Indeed, seems superfluous...
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/dma/at_xdmac.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
> index b7d7f2d443a1..8c1abb794340 100644
> --- a/drivers/dma/at_xdmac.c
> +++ b/drivers/dma/at_xdmac.c
> @@ -221,7 +221,6 @@ struct at_xdmac {
> int irq;
> struct clk *clk;
> u32 save_gim;
> - u32 save_gs;
> struct dma_pool *at_xdmac_desc_pool;
> struct at_xdmac_chan chan[0];
> };
> @@ -1896,7 +1895,6 @@ static int atmel_xdmac_resume(struct device *dev)
> }
>
> at_xdmac_write(atxdmac, AT_XDMAC_GIE, atxdmac->save_gim);
> - at_xdmac_write(atxdmac, AT_XDMAC_GE, atxdmac->save_gs);
> list_for_each_entry_safe(chan, _chan, &atxdmac->dma.channels, device_node) {
> atchan = to_at_xdmac_chan(chan);
> at_xdmac_chan_write(atchan, AT_XDMAC_CC, atchan->save_cc);
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v5 net-next 4/7] net: mvneta: Convert to be 64 bits compatible
From: Jisheng Zhang @ 2016-12-01 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b4d20a85b05e93d254e265eb07569dd1285d303.1480542157.git-series.gregory.clement@free-electrons.com>
Hi Gregory, Marcin,
On Wed, 30 Nov 2016 22:42:49 +0100 Gregory CLEMENT wrote:
> From: Marcin Wojtas <mw@semihalf.com>
>
> Prepare the mvneta driver in order to be usable on the 64 bits platform
> such as the Armada 3700.
>
> [gregory.clement at free-electrons.com]: this patch was extract from a larger
> one to ease review and maintenance.
>
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> drivers/net/ethernet/marvell/mvneta.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index 92b9af14c352..8ef03fb69bcd 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -296,6 +296,12 @@
> /* descriptor aligned size */
> #define MVNETA_DESC_ALIGNED_SIZE 32
>
> +/* Number of bytes to be taken into account by HW when putting incoming data
> + * to the buffers. It is needed in case NET_SKB_PAD exceeds maximum packet
> + * offset supported in MVNETA_RXQ_CONFIG_REG(q) registers.
We also brought up this driver on 64bit platforms, we doesn't have this
patch. Maybe I'm wrong, I'm trying to understand why we need this
modification. Let's assume the NET_SKB_PAD is 64B, we call
mvneta_rxq_offset_set(pp, rxq, 64),
{
u32 val;
val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id));
val &= ~MVNETA_RXQ_PKT_OFFSET_ALL_MASK;
/* Offset is in */
val |= MVNETA_RXQ_PKT_OFFSET_MASK(offset >> 3);
// then this will be "val |= 8;" it doesn't exceeds the max offset of
MVNETA_RXQ_CONFIG_REG(q) register.
Could you please kindly point out where I am wrong?
> + */
> +#define MVNETA_RX_PKT_OFFSET_CORRECTION 64
> +
> #define MVNETA_RX_PKT_SIZE(mtu) \
> ALIGN((mtu) + MVNETA_MH_SIZE + MVNETA_VLAN_TAG_LEN + \
> ETH_HLEN + ETH_FCS_LEN, \
> @@ -416,6 +422,7 @@ struct mvneta_port {
> u64 ethtool_stats[ARRAY_SIZE(mvneta_statistics)];
>
> u32 indir[MVNETA_RSS_LU_TABLE_SIZE];
> + u16 rx_offset_correction;
> };
>
> /* The mvneta_tx_desc and mvneta_rx_desc structures describe the
> @@ -1807,6 +1814,7 @@ static int mvneta_rx_refill(struct mvneta_port *pp,
> return -ENOMEM;
> }
>
> + phys_addr += pp->rx_offset_correction;
> mvneta_rx_desc_fill(rx_desc, phys_addr, data, rxq);
> return 0;
> }
> @@ -2782,7 +2790,7 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
> mvreg_write(pp, MVNETA_RXQ_SIZE_REG(rxq->id), rxq->size);
>
> /* Set Offset */
> - mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD);
> + mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD - pp->rx_offset_correction);
>
> /* Set coalescing pkts and time */
> mvneta_rx_pkts_coal_set(pp, rxq, rxq->pkts_coal);
> @@ -4033,6 +4041,13 @@ static int mvneta_probe(struct platform_device *pdev)
>
> pp->rxq_def = rxq_def;
>
> + /* Set RX packet offset correction for platforms, whose
> + * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit
> + * platforms and 0B for 32-bit ones.
Even we need this patch, I'm not sure this last comment is correct or not.
NET_SKB_PAD is defined as:
#define NET_SKB_PAD max(32, L1_CACHE_BYTES)
we have 64B cacheline 32bit platforms, on this platforms, the NET_SKB_PAD
should be 64B as well.
Thanks,
Jisheng
^ permalink raw reply
* [PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration
From: Lorenzo Pieralisi @ 2016-12-01 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c89825aa-c75f-8493-fe92-7cc97f525bc7@arm.com>
On Wed, Nov 30, 2016 at 04:42:27PM +0000, Robin Murphy wrote:
> On 30/11/16 16:17, Lorenzo Pieralisi wrote:
> > Sricharan, Robin,
> >
> > I gave this series a go on ACPI and apart from an SMMU v3 fix-up
> > it seems to work, more thorough testing required though.
> >
> > A key question below.
> >
> > On Wed, Nov 30, 2016 at 05:52:16AM +0530, Sricharan R wrote:
> >> From: Robin Murphy <robin.murphy@arm.com>
> >>
> >> IOMMU configuration represents unchanging properties of the hardware,
> >> and as such should only need happen once in a device's lifetime, but
> >> the necessary interaction with the IOMMU device and driver complicates
> >> exactly when that point should be.
> >>
> >> Since the only reasonable tool available for handling the inter-device
> >> dependency is probe deferral, we need to prepare of_iommu_configure()
> >> to run later than it is currently called (i.e. at driver probe rather
> >> than device creation), to handle being retried, and to tell whether a
> >> not-yet present IOMMU should be waited for or skipped (by virtue of
> >> having declared a built-in driver or not).
> >>
> >> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >> ---
> >> drivers/iommu/of_iommu.c | 30 +++++++++++++++++++++++++++++-
> >> 1 file changed, 29 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> >> index ee49081..349bd1d 100644
> >> --- a/drivers/iommu/of_iommu.c
> >> +++ b/drivers/iommu/of_iommu.c
> >> @@ -104,12 +104,20 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
> >> int err;
> >>
> >> ops = iommu_get_instance(fwnode);
> >> - if (!ops || !ops->of_xlate)
> >> + if ((ops && !ops->of_xlate) ||
> >> + (!ops && !of_match_node(&__iommu_of_table, iommu_spec->np)))
> >
> > IIUC of_match_node() here is there to check there is a driver compiled
> > in for this device_node (aka compatible string in OF world), correct ?
>
> Yes - specifically, it's checking the magic table for a matching
> IOMMU_OF_DECLARE entry.
>
> > If that's the case (and I think that's what Sricharan was referring to
> > in his ACPI query) I need to cook-up something on the ACPI side to
> > emulate the OF linker table behaviour (or anyway to detect a driver is
> > actually in the kernel), it is not that difficult but it is key to know,
> > I will give it some thought to make it as clean as possible.
>
> I didn't think this would be a concern for ACPI, since IORT works much
> the same way the current of_iommu_init_fn/of_platform_device_create()
> bodges in drivers so for DT. If you can only discover SMMUs from IORT,
> then iort_init_platform_devices() will have already created every SMMU
> that's going to exist before discovering other devices from wherever
> they come from, thus you could never get into the situation of probing a
> device without its SMMU being ready (if it's ever going to be). Is that
> not right?
It is right, my point and question is: we are probing a device and we
have to know whether it is worth deferring its IOMMU DMA setup. On DT,
through of_match_node(&__iommu_of_table, iommu_device_node) we check at
once that:
1 - A device for the IOMMU exists
AND
2 - A driver for the IOMMU is compiled in the kernel
Is this correct ? As you said (1) is not a concern on ACPI IORT (because
we create the IOMMU device before _any_ other device so either the IOMMU
device is there or it will never be by the time master devices are
probed), but for (2) I need to slightly change how the IORT linker entry
work to make sure we can detect a driver is actually compiled in the
kernel, it is easy, I was just asking if my understanding was correct
and I think that was what Sricharan was referring to in his query.
I will put together a patch, again, it is a simple tweak.
Thanks !
Lorenzo
> Robin.
>
> >
> > Thanks,
> > Lorenzo
> >
> >> return NULL;
> >>
> >> err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
> >> if (err)
> >> return ERR_PTR(err);
> >> + /*
> >> + * The otherwise-empty fwspec handily serves to indicate the specific
> >> + * IOMMU device we're waiting for, which will be useful if we ever get
> >> + * a proper probe-ordering dependency mechanism in future.
> >> + */
> >> + if (!ops)
> >> + return ERR_PTR(-EPROBE_DEFER);
> >>
> >> err = ops->of_xlate(dev, iommu_spec);
> >> if (err)
> >> @@ -186,14 +194,34 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
> >> struct device_node *master_np)
> >> {
> >> const struct iommu_ops *ops;
> >> + struct iommu_fwspec *fwspec = dev->iommu_fwspec;
> >>
> >> if (!master_np)
> >> return NULL;
> >>
> >> + if (fwspec) {
> >> + if (fwspec->ops)
> >> + return fwspec->ops;
> >> +
> >> + /* In the deferred case, start again from scratch */
> >> + iommu_fwspec_free(dev);
> >> + }
> >> +
> >> if (dev_is_pci(dev))
> >> ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
> >> else
> >> ops = of_platform_iommu_init(dev, master_np);
> >> + /*
> >> + * If we have reason to believe the IOMMU driver missed the initial
> >> + * add_device callback for dev, replay it to get things in order.
> >> + */
> >> + if (!IS_ERR_OR_NULL(ops) && ops->add_device &&
> >> + dev->bus && !dev->iommu_group) {
> >> + int err = ops->add_device(dev);
> >> +
> >> + if (err)
> >> + ops = ERR_PTR(err);
> >> + }
> >>
> >> return IS_ERR(ops) ? NULL : ops;
> >> }
> >> --
> >> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> >>
>
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Jean-Francois Moine @ 2016-12-01 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5021537.YAZCMeDTSh@avalon>
On Thu, 01 Dec 2016 12:41:20 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> > > If a DVI connector instead of a HDMI connector is soldered, how
> > > should such a device tree be written?
> >
> > Use a dvi-connector instead :)
>
> The HDMI encoder DT node doesn't (and certainly shouldn't) report what type of
> connector is mounted on the board. Having a connector node in DT makes the
> connector type available to the system, allowing the DRM driver to expose the
> right connector type to userspace (it would be confusing for the user to
> report DRM_MODE_CONNECTOR_HDMIA for a DVI connector).
The connector type, HDMI or DVI, is known by the EDID.
The user is not interested by the software indication of the connector
type: (s)he knows it because (s)he connected him/herself the display
device.
And the DRM driver does not do anything from the knowledge of the
connector type in the DT. Only the EDID may tell if the display device
may do audio streaming (direct HDMI with audio capability) or not
(direct HDMI without audio, HDMI to DVI cable, DVI physical connector).
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [bug report v4.8] fs/locks.c: kernel oops during posix lock stress test
From: Will Deacon @ 2016-12-01 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACVXFVPsHjh3CWjdUrKB_r6=hkXK=qS3wpykbacdKe1rzz1H8Q@mail.gmail.com>
On Mon, Nov 28, 2016 at 11:10:14AM +0800, Ming Lei wrote:
> When I run stress-ng via the following steps on one ARM64 dual
> socket system(Cavium Thunder), the kernel oops[1] can often be
> triggered after running the stress test for several hours(sometimes
> it may take longer):
>
> - git clone git://kernel.ubuntu.com/cking/stress-ng.git
> - apply the attachment patch which just makes the posix file
> lock stress test more aggressive
> - run the test via '~/git/stress-ng$./stress-ng --lockf 128 --aggressive'
>
>
> From the oops log, looks one garbage file_lock node is got
> from the linked list of 'ctx->flc_posix' when the issue happens.
>
> BTW, the issue isn't observed on single socket Cavium Thunder yet,
> and the same issue can be seen on Ubuntu Xenial(v4.4 based kernel)
> too.
FWIW, I've been running this on Seattle for 24 hours with your patch applied
and not seen any problems yet. That said, Thomas did just fix an rt_mutex
race which only seemed to pop up on Thunder, so you could give those
patches a try.
https://lkml.kernel.org/r/20161130205431.629977871 at linutronix.de
Will
^ 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