* [PATCH 3/7] KVM: arm/arm64: Register perf trace event notifier
From: Punit Agrawal @ 2016-09-13 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473761769-30572-1-git-send-email-punit.agrawal@arm.com>
Register a notifier to track state changes of perf trace events.
The notifier will enable taking appropriate action for trace events
targeting VM.
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm/include/asm/kvm_host.h | 3 +
arch/arm/kvm/arm.c | 2 +
arch/arm64/include/asm/kvm_host.h | 8 +++
arch/arm64/kvm/Kconfig | 4 ++
arch/arm64/kvm/Makefile | 1 +
arch/arm64/kvm/perf_trace.c | 122 ++++++++++++++++++++++++++++++++++++++
6 files changed, 140 insertions(+)
create mode 100644 arch/arm64/kvm/perf_trace.c
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index de338d9..609998e 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -280,6 +280,9 @@ static inline int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
int kvm_perf_init(void);
int kvm_perf_teardown(void);
+static inline int kvm_perf_trace_init(void) { return 0; }
+static inline int kvm_perf_trace_teardown(void) { return 0; }
+
void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot);
struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 75f130e..e1b99c4 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -1220,6 +1220,7 @@ static int init_subsystems(void)
goto out;
kvm_perf_init();
+ kvm_perf_trace_init();
kvm_coproc_table_init();
out:
@@ -1411,6 +1412,7 @@ out_err:
void kvm_arch_exit(void)
{
kvm_perf_teardown();
+ kvm_perf_trace_teardown();
}
static int arm_init(void)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 3eda975..f6ff8e5 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -345,6 +345,14 @@ int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
int kvm_perf_init(void);
int kvm_perf_teardown(void);
+#if !defined(CONFIG_KVM_PERF_TRACE)
+static inline int kvm_perf_trace_init(void) { return 0; }
+static inline int kvm_perf_trace_teardown(void) { return 0; }
+#else
+int kvm_perf_trace_init(void);
+int kvm_perf_trace_teardown(void);
+#endif
+
struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr,
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index 9c9edc9..56e9537 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -19,6 +19,9 @@ if VIRTUALIZATION
config KVM_ARM_VGIC_V3
bool
+config KVM_PERF_TRACE
+ bool
+
config KVM
bool "Kernel-based Virtual Machine (KVM) support"
depends on OF
@@ -39,6 +42,7 @@ config KVM
select HAVE_KVM_MSI
select HAVE_KVM_IRQCHIP
select HAVE_KVM_IRQ_ROUTING
+ select KVM_PERF_TRACE if EVENT_TRACING && PERF_EVENTS
---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 695eb3c..7d175e4 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -19,6 +19,7 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(ARM)/psci.o $(ARM)/perf.o
kvm-$(CONFIG_KVM_ARM_HOST) += emulate.o inject_fault.o regmap.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_PERF_TRACE) += perf_trace.o
kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic.o
kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-init.o
diff --git a/arch/arm64/kvm/perf_trace.c b/arch/arm64/kvm/perf_trace.c
new file mode 100644
index 0000000..1cafbc9
--- /dev/null
+++ b/arch/arm64/kvm/perf_trace.c
@@ -0,0 +1,122 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ * Author: Punit Agrawal <punit.agrawal@arm.com>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+#include <linux/kvm_host.h>
+#include <linux/trace_events.h>
+
+typedef int (*perf_trace_callback_fn)(struct kvm *kvm, bool enable);
+
+struct kvm_trace_hook {
+ char *key; /* Name of the tracepoint to match */
+ perf_trace_callback_fn setup_fn;
+};
+
+static struct kvm_trace_hook trace_hook[] = {
+ { },
+};
+
+static perf_trace_callback_fn find_trace_callback(const char *trace_key)
+{
+ int i;
+
+ for (i = 0; trace_hook[i].key; i++)
+ if (!strcmp(trace_key, trace_hook[i].key))
+ return trace_hook[i].setup_fn;
+
+ return NULL;
+}
+
+static int kvm_perf_trace_notifier(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct perf_event *p_event = data;
+ struct trace_event_call *tp_event = p_event->tp_event;
+ perf_trace_callback_fn setup_trace_fn;
+ struct kvm *kvm = NULL;
+ struct pid *pid;
+ bool found = false;
+
+ /*
+ * Is this a trace point?
+ */
+ if (!(tp_event->flags & TRACE_EVENT_FL_TRACEPOINT))
+ goto out;
+
+ /*
+ * We'll get here for events we care to monitor for KVM. As we
+ * only care about events attached to a VM, check that there
+ * is a task associated with the perf event.
+ */
+ if (p_event->attach_state != PERF_ATTACH_TASK)
+ goto out;
+
+ /*
+ * This notifier gets called when perf trace event instance is
+ * added or removed. Until we can restrict this to events of
+ * interest in core, minimise the overhead below.
+ *
+ * Do we care about it? i.e., is there a callback for this
+ * trace point?
+ */
+ setup_trace_fn = find_trace_callback(tp_event->tp->name);
+ if (!setup_trace_fn)
+ goto out;
+
+ pid = get_task_pid(p_event->hw.target, PIDTYPE_PID);
+
+ /*
+ * Does it match any of the VMs?
+ */
+ spin_lock(&kvm_lock);
+ list_for_each_entry(kvm, &vm_list, vm_list) {
+ if (kvm->pid == pid) {
+ found = true;
+ break;
+ }
+ }
+ spin_unlock(&kvm_lock);
+
+ put_pid(pid);
+ if (!found)
+ goto out;
+
+ switch (event) {
+ case TRACE_REG_PERF_OPEN:
+ setup_trace_fn(kvm, true);
+ break;
+
+ case TRACE_REG_PERF_CLOSE:
+ setup_trace_fn(kvm, false);
+ break;
+ }
+
+out:
+ return 0;
+}
+
+static struct notifier_block kvm_perf_trace_notifier_block = {
+ .notifier_call = kvm_perf_trace_notifier,
+};
+
+int kvm_perf_trace_init(void)
+{
+ return perf_trace_notifier_register(&kvm_perf_trace_notifier_block);
+}
+
+int kvm_perf_trace_teardown(void)
+{
+ return perf_trace_notifier_unregister(&kvm_perf_trace_notifier_block);
+}
--
2.8.1
^ permalink raw reply related
* [PATCH 2/7] KVM: Track the pid of the VM process
From: Punit Agrawal @ 2016-09-13 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473761769-30572-1-git-send-email-punit.agrawal@arm.com>
Userspace tools such as perf can be used to profile individual
processes.
Track the PID of the virtual machine process to match profiling requests
targeted at it. This can be used to take appropriate action to enable
the requested profiling operations for the VMs of interest.
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Kr?m??" <rkrcmar@redhat.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 9c28b4d..7c42c94 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -374,6 +374,7 @@ struct kvm_memslots {
struct kvm {
spinlock_t mmu_lock;
struct mutex slots_lock;
+ struct pid *pid;
struct mm_struct *mm; /* userspace tied to this vm */
struct kvm_memslots *memslots[KVM_ADDRESS_SPACE_NUM];
struct srcu_struct srcu;
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 1950782..d87231a 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -613,6 +613,7 @@ static struct kvm *kvm_create_vm(unsigned long type)
spin_lock_init(&kvm->mmu_lock);
atomic_inc(¤t->mm->mm_count);
kvm->mm = current->mm;
+ kvm->pid = get_task_pid(current->group_leader, PIDTYPE_PID);
kvm_eventfd_init(kvm);
mutex_init(&kvm->lock);
mutex_init(&kvm->irq_lock);
@@ -712,6 +713,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
int i;
struct mm_struct *mm = kvm->mm;
+ put_pid(kvm->pid);
kvm_destroy_vm_debugfs(kvm);
kvm_arch_sync_events(kvm);
spin_lock(&kvm_lock);
--
2.8.1
^ permalink raw reply related
* [PATCH 1/7] perf/trace: Add notification for perf trace events
From: Punit Agrawal @ 2016-09-13 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473761769-30572-1-git-send-email-punit.agrawal@arm.com>
Add a mechanism to notify listeners about perf trace event state
changes. This enables listeners to take actions requiring the event
context (e.g., attached process).
The notification mechanism can be used to reduce trace point based
profiling overhead by enabling/disabling hardware traps for specific
contexts (e.g., virtual machines).
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@redhat.com>
---
include/linux/trace_events.h | 3 +++
kernel/trace/trace_event_perf.c | 24 ++++++++++++++++++++++++
2 files changed, 27 insertions(+)
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index be00761..5924032 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -505,6 +505,9 @@ perf_trace_buf_submit(void *raw_data, int size, int rctx, u16 type,
{
perf_tp_event(type, count, raw_data, size, regs, head, rctx, task);
}
+
+extern int perf_trace_notifier_register(struct notifier_block *nb);
+extern int perf_trace_notifier_unregister(struct notifier_block *nb);
#endif
#endif /* _LINUX_TRACE_EVENT_H */
diff --git a/kernel/trace/trace_event_perf.c b/kernel/trace/trace_event_perf.c
index 562fa69..9aaaacf 100644
--- a/kernel/trace/trace_event_perf.c
+++ b/kernel/trace/trace_event_perf.c
@@ -6,10 +6,12 @@
*/
#include <linux/module.h>
+#include <linux/notifier.h>
#include <linux/kprobes.h>
#include "trace.h"
static char __percpu *perf_trace_buf[PERF_NR_CONTEXTS];
+static RAW_NOTIFIER_HEAD(perf_trace_notifier_list);
/*
* Force it to be aligned to unsigned long to avoid misaligned accesses
@@ -86,6 +88,26 @@ static int perf_trace_event_perm(struct trace_event_call *tp_event,
return 0;
}
+int perf_trace_notifier_register(struct notifier_block *nb)
+{
+ return raw_notifier_chain_register(&perf_trace_notifier_list, nb);
+}
+
+int perf_trace_notifier_unregister(struct notifier_block *nb)
+{
+ return raw_notifier_chain_unregister(&perf_trace_notifier_list, nb);
+}
+
+static void perf_trace_notify(enum trace_reg event, struct perf_event *p_event)
+{
+ /*
+ * We use raw notifiers here as we are called with the
+ * event_mutex held.
+ */
+ raw_notifier_call_chain(&perf_trace_notifier_list,
+ event, p_event);
+}
+
static int perf_trace_event_reg(struct trace_event_call *tp_event,
struct perf_event *p_event)
{
@@ -176,6 +198,7 @@ out:
static int perf_trace_event_open(struct perf_event *p_event)
{
struct trace_event_call *tp_event = p_event->tp_event;
+ perf_trace_notify(TRACE_REG_PERF_OPEN, p_event);
return tp_event->class->reg(tp_event, TRACE_REG_PERF_OPEN, p_event);
}
@@ -183,6 +206,7 @@ static void perf_trace_event_close(struct perf_event *p_event)
{
struct trace_event_call *tp_event = p_event->tp_event;
tp_event->class->reg(tp_event, TRACE_REG_PERF_CLOSE, p_event);
+ perf_trace_notify(TRACE_REG_PERF_CLOSE, p_event);
}
static int perf_trace_event_init(struct trace_event_call *tp_event,
--
2.8.1
^ permalink raw reply related
* [PATCH 0/7] Add support for monitoring guest TLB operations
From: Punit Agrawal @ 2016-09-13 10:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Although there are no PMU events to monitor TLB operations, ARMv8
supports trapping guest TLB maintenance operations to the
hypervisor. This trapping mechanism can be used to monitor the use of
guest TLB instructions.
As taking a trap for every TLB operation can have significant
overhead, trapping should only be enabled -
* on user request
* for the VM of interest
This patchset adds support to listen to perf trace event state change
notifications. The notifications and associated context are then used
to enable trapping of guest TLB operations when requested by the
user. The trap handling generates trace events (kvm_tlb_invalidate)
which can already be counted using existing perf trace functionality.
I would appreciate feedback on the approach to tie the control of TLB
monitoring with perf trace events (Patch 1) especially if there are
any suggestions on avoiding (or reducing) the overhead of "perf trace"
notifications.
I looked at using regfunc/unregfunc tracepoint hooks but they don't
include the event context. But the bigger problem was that the
callbacks are only called on the first instance of simultaneously
executing perf stat invocations.
The patchset is based on v4.8-rc5 and adds support for monitoring
guest TLB operations on 64bit hosts. If the approach taken in the
patches is acceptable, I'll add 32bit host support as well.
Earlier discussion on this patchset can be found at [0][1].
Changes:
RFC v2 -> v1
* Dropped the RFC tag
* Patch 2 - Use VM thread group id for identification
* Patch 4 - Update comment for clarity
* Patch 6 - Add comment explaining switch to hype-role when VHE is enabled
* Patch 7 - Add comment to clarify struct kvm_trace_hook
RFC -> RFC v2
* Patch 4 - Rename left-over TLBI macro to __TLBI
* Patch 6 - Replace individual TLB operation emulation with
invalidating all stage 1 TLB for the VM. TLB monitoring is expected
to be a debug feature and performance is not critical.
With this patchset, 'perf' tool when attached to a VM process can be
used to monitor the TLB operations. E.g., to monitor a VM with process
id 4166 -
# perf stat -e "kvm:kvm_tlb_invalidate" -p 4166
Perform some operations in VM (running 'make -j 7' on the kernel
sources in this instance). Breaking out of perf shows -
Performance counter stats for process id '4166':
7,471,974 kvm:kvm_tlb_invalidate
374.235405282 seconds time elapsed
All feedback welcome.
Thanks,
Punit
[0] http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1210715.html
[1] http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1224353.html
Mark Rutland (2):
arm64: tlbflush.h: add __tlbi() macro
arm64/kvm: hyp: tlb: use __tlbi() helper
Punit Agrawal (5):
perf/trace: Add notification for perf trace events
KVM: Track the pid of the VM process
KVM: arm/arm64: Register perf trace event notifier
arm64: KVM: Handle trappable TLB instructions
arm64: KVM: Enable selective trapping of TLB instructions
arch/arm/include/asm/kvm_host.h | 3 +
arch/arm/kvm/arm.c | 2 +
arch/arm64/include/asm/kvm_asm.h | 1 +
arch/arm64/include/asm/kvm_host.h | 8 ++
arch/arm64/include/asm/tlbflush.h | 34 +++++++--
arch/arm64/kvm/Kconfig | 4 +
arch/arm64/kvm/Makefile | 1 +
arch/arm64/kvm/hyp/tlb.c | 87 +++++++++++++++++++--
arch/arm64/kvm/perf_trace.c | 154 ++++++++++++++++++++++++++++++++++++++
arch/arm64/kvm/sys_regs.c | 81 ++++++++++++++++++++
arch/arm64/kvm/trace.h | 16 ++++
include/linux/kvm_host.h | 1 +
include/linux/trace_events.h | 3 +
kernel/trace/trace_event_perf.c | 24 ++++++
virt/kvm/kvm_main.c | 2 +
15 files changed, 407 insertions(+), 14 deletions(-)
create mode 100644 arch/arm64/kvm/perf_trace.c
--
2.8.1
^ permalink raw reply
* [PATCH v4 07/10] ARM: Introduce MPIDR_LEVEL_SHIFT macro
From: Marc Zyngier @ 2016-09-13 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D7C111.7000405@arm.com>
On 13/09/16 10:04, Vladimir Murzin wrote:
> On 13/09/16 09:38, Christoffer Dall wrote:
>> On Mon, Sep 12, 2016 at 03:49:21PM +0100, Vladimir Murzin wrote:
>>> vgic-v3 driver uses architecture specific MPIDR_LEVEL_SHIFT macro to
>>> encode the affinity in a form compatible with ICC_SGI* registers.
>>> Unfortunately, that macro is missing on ARM, so let's add it.
>>>
>>> Cc: Russell King <rmk+kernel@armlinux.org.uk>
>>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>>> ---
>>> arch/arm/include/asm/cputype.h | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
>>> index 1ee94c7..e2d94c1 100644
>>> --- a/arch/arm/include/asm/cputype.h
>>> +++ b/arch/arm/include/asm/cputype.h
>>> @@ -55,6 +55,7 @@
>>>
>>> #define MPIDR_LEVEL_BITS 8
>>> #define MPIDR_LEVEL_MASK ((1 << MPIDR_LEVEL_BITS) - 1)
>>> +#define MPIDR_LEVEL_SHIFT(level) (MPIDR_LEVEL_BITS * level)
>>>
>>
>> I'm not sure I follow the correctness of this completely.
>>
>> This is called from vgic_v3_dispatch_sgi, which takes a u64 value, which
>> may have something in the Aff3 field, which we now shift left 24 bits,
>> but that is not the Aff3 field of AArch32's MPIDR.
>>
>> What is the rationale for this making sense again?
>
> IIUC, in such case we construct mpidr which won't match in match_mpidr()
> with the value we get from kvm_vcpu_get_mpidr_aff() and no SGI will be
> sent to the guest.
>
> Since we get that u64 value from the guest, I'd think it is something
> wrong is going on in the guest in case Aff3 is non-zero; however, we can
> hide it by zeroing out SGI Aff3 bits in access_gic_sgi().
I don't think zeroing Aff3 is the right move, as the spec doesn't say
that Aff3 should be ignored in a write to ICC_SGI1R. On the other hand,
the spec says (in the context of the target list): "If a bit is 1 and
the bit does not correspond to a valid target PE, the bit must be
ignored by the Distributor".
This makes me think that, unless ICC_SGI1R.IMR is set, we should simply
ignore that SGI because there is no way we can actually deliver it.
Could you cook a small patch that would go on top of this series?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v1 1/2] ARM: dts: add rockchip PX3 Evaluation board
From: Andy Yan @ 2016-09-13 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473529440-6202-1-git-send-email-andy.yan@rock-chips.com>
Hi Heiko:
Is there any further suggestion about this series?
On 2016?09?11? 01:44, Andy Yan wrote:
> PX3 EVB is designed by Rockchip for automotive field,
> which intergrated with CVBS(TP2825)/MIPI DSI/LVDS/HDMI
> video input/output interface, WIFI/BT/GPS(on a module
> named S500 which based on MT6620), Gsensor BMA250E and
> light&proximity sensor STK3410.
>
> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
>
> ---
>
> Changes in v1:
> - board rename
> - add vendor prefix for i2c interfaced sensors
> - use stdout-path to set the default console
>
> Documentation/devicetree/bindings/arm/rockchip.txt | 4 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/rk3188-px3-evb.dts | 337 +++++++++++++++++++++
> 3 files changed, 342 insertions(+)
> create mode 100644 arch/arm/boot/dts/rk3188-px3-evb.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
> index 6668645..6da3881 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -21,6 +21,10 @@ Rockchip platforms device tree bindings
> Required root node properties:
> - compatible = "radxa,rock", "rockchip,rk3188";
>
> +- Rockchip PX3 Evaluation board:
> + Required root node properties:
> + - compatible = "rockchip,px3-evb", "rockchip,px3", "rockchip,rk3188";
> +
> - Radxa Rock2 Square board:
> Required root node properties:
> - compatible = "radxa,rock2-square", "rockchip,rk3288";
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index faacd52..88d27a2 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -620,6 +620,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> rk3066a-marsboard.dtb \
> rk3066a-rayeager.dtb \
> rk3188-radxarock.dtb \
> + rk3188-px3-evb.dtb \
> rk3228-evb.dtb \
> rk3229-evb.dtb \
> rk3288-evb-act8846.dtb \
> diff --git a/arch/arm/boot/dts/rk3188-px3-evb.dts b/arch/arm/boot/dts/rk3188-px3-evb.dts
> new file mode 100644
> index 0000000..f6bc738
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk3188-px3-evb.dts
> @@ -0,0 +1,337 @@
> +/*
> + * Copyright (c) 2016 Andy Yan <andy.yan@rock-chips.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (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.
> + */
> +
> +/dts-v1/;
> +#include <dt-bindings/input/input.h>
> +#include "rk3188.dtsi"
> +
> +/ {
> + model = "Rockchip PX3-EVB";
> + compatible = "rockchip,px3-evb", "rockchip,px3", "rockchip,rk3188";
> +
> + chosen {
> + stdout-path = "serial2:115200n8";
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x60000000 0x80000000>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + autorepeat;
> +
> + power {
> + gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
> + linux,code = <KEY_POWER>;
> + label = "GPIO Key Power";
> + linux,input-type = <1>;
> + wakeup-source;
> + debounce-interval = <100>;
> + };
> + };
> +
> + vcc_sys: vsys-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vsys";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-boot-on;
> + };
> +};
> +
> +&cpu0 {
> + cpu0-supply = <&vdd_cpu>;
> +};
> +
> +&i2c0 {
> + status = "okay";
> +
> + /* Accelerometer */
> + bma250 at 18 {
> + compatible = "bosch,bma250";
> + reg = <0x18>;
> + interrupt-parent = <&gpio0>;
> + interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
> + };
> +
> + stk3410 at 48 {
> + compatible = "sensortek,STK3310";
> + reg = <0x48>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
> + };
> +};
> +
> +&i2c1 {
> + status = "okay";
> + clock-frequency = <400000>;
> + rk808: pmic at 1c {
> + compatible = "rockchip,rk818";
> + reg = <0x1c>;
> + interrupt-parent = <&gpio0>;
> + interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> + rockchip,system-power-controller;
> + wakeup-source;
> + #clock-cells = <1>;
> + clock-output-names = "xin32k", "rk808-clkout2";
> +
> + vcc1-supply = <&vcc_sys>;
> + vcc2-supply = <&vcc_sys>;
> + vcc3-supply = <&vcc_sys>;
> + vcc4-supply = <&vcc_sys>;
> + vcc6-supply = <&vcc_sys>;
> + vcc7-supply = <&vcc_sys>;
> + vcc8-supply = <&vcc_io>;
> + vcc9-supply = <&vcc_io>;
> +
> + regulators {
> + vdd_cpu: DCDC_REG1 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <750000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-name = "vdd_arm";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vdd_gpu: DCDC_REG2 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <850000>;
> + regulator-max-microvolt = <1250000>;
> + regulator-name = "vdd_gpu";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1000000>;
> + };
> + };
> +
> + vcc_ddr: DCDC_REG3 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-name = "vcc_ddr";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vcc_io: DCDC_REG4 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc_io";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3300000>;
> + };
> + };
> +
> + vcc_cif: LDO_REG1 {
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc_cif";
> + };
> +
> + vcc_jetta33: LDO_REG2 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc_jetta33";
> + };
> +
> + vdd_10: LDO_REG3 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + regulator-name = "vdd_10";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1000000>;
> + };
> + };
> +
> + lvds_12: LDO_REG4 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-name = "lvds_12";
> + };
> +
> + lvds_25: LDO_REG5 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "lvds_25";
> + };
> +
> + cif_18: LDO_REG6 {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + regulator-name = "cif_18";
> + };
> +
> + vcc_sd: LDO_REG7 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc_sd";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3300000>;
> + };
> + };
> +
> + wl_18: LDO_REG8 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "wl_18";
> + };
> +
> + lcd_33: SWITCH_REG1 {
> + regulator-name = "lcd_33";
> + };
> + };
> + };
> +
> +};
> +
> +&i2c2 {
> + gsl1680: touchscreen at 40 {
> + compatible = "silead,gsl1680";
> + reg = <0x40>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
> + power-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
> + touchscreen-size-x = <800>;
> + touchscreen-size-y = <1280>;
> + silead,max-fingers = <5>;
> + };
> +};
> +
> +&emmc {
> + bus-width = <8>;
> + cap-mmc-highspeed;
> + disable-wp;
> + non-removable;
> + num-slots = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&emmc_clk>, <&emmc_cmd>, <&emmc_rst>;
> + status = "okay";
> +};
> +
> +&mmc0 {
> + num-slots = <1>;
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&sd0_clk>, <&sd0_cmd>, <&sd0_cd>, <&sd0_bus4>;
> + vmmc-supply = <&vcc_sd>;
> +
> + bus-width = <4>;
> + cap-mmc-highspeed;
> + cap-sd-highspeed;
> + disable-wp;
> +};
> +
> +&pwm1 {
> + status = "okay";
> +};
> +
> +&pwm2 {
> + status = "okay";
> +};
> +
> +&pwm3 {
> + status = "okay";
> +};
> +
> +&pinctrl {
> + pcfg_output_low: pcfg-output-low {
> + output-low;
> + };
> +
> + usb {
> + host_vbus_drv: host-vbus-drv {
> + rockchip,pins = <0 3 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + otg_vbus_drv: otg-vbus-drv {
> + rockchip,pins = <2 31 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
> +
> +&uart3 {
> + status = "okay";
> +};
> +
> +&usbphy {
> + status = "okay";
> +};
> +
> +&usb_host {
> + status = "okay";
> +};
> +
> +&usb_otg {
> + status = "okay";
> +};
> +
> +&wdt {
> + status = "okay";
> +};
^ permalink raw reply
* ARM, SoC: About the use DT-defined properties by 3rd-party drivers
From: Sebastian Frias @ 2016-09-13 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912165637.GF14165@leverpostej>
Hi Mark,
On 09/12/2016 06:56 PM, Mark Rutland wrote:
>> Exactly, that's why to I'm having trouble to understand why there is so much
>> insistence on "getting the DT 100% right", since a HW change could imply
>> that what made 100% sense yesterday, does not today.
>> Since that is a possibility we have to live with, then the "100% right" goal
>> is most likely unachievable.
>> That's different from "backwards compatibility" for which some technique,
>> like alternate descriptions, can be put in place.
>
> I'm not on about "100% right", but more "a reasonable chance of being
> good enough".
Ok.
> The latter is extremely difficult to judge when you just
> get a binding document with little or no additional context.
Exactly, that is why I was thinking it would take less "review" time.
Indeed, if there is no driver, why would it matter what those bindings
are?
> Backwards compatibility is with regards to new software supporting old
> bindings. If new HW comes out, we can create new bindings. Old bindings
> should remain supported regardless.
Indeed. So you agree that without a driver, there is no backward compatibility
to maintain (because nothing could break).
Could we then say that in that case, it should not matter that much (if at all)
if the bindings have "a reasonable chance of being good enough"?
Because I'm trying to understand why/how would the "open-source community" be
affected by some DT properties/nodes that are not used by upstream Linux drivers.
Warner proposed 'overlays' to deal with the "open-source community" reticence to
accept such bindings.
Whereas it may be simpler to just find a way to accommodate the integration of
such bindings in a way that everybody wins.
That could take the form of a "staging" DT area, so that the 'overlay' is public.
Just for the sake and benefit of everybody, 3rd parties and open-source community.
>> Could you be more precise on those two issues? Namely:
>> "the effort" and the "lack of benefit for the community"?
>
> As above, reviewing is tricky. One has to spend the time gaining an
> understanding of a particular piece of hardware, the class of hardware
> it falls in, and also the bigger picture that it fits in. Once you have
> that, you have to review the binding in that context, and that takes
> time and effort.
Yes, but this is based on a binding for which there's a driver.
If there's no driver it should not take that much time, right?
> As things evolve, perhaps mistakes or inconsistencies are found, or new
> ways to generalise things. As that occurs, there is a maintenance burden
> for existing bindings.
>
> All of that takes time and effort.
Only for bindings for which there is a driver.
Think about this:
- a binding with no driver is submitted and ends up in the tree
(it could be on a staging area if necessary)
- if at a later point somebody attempts to upstream a driver using those
'staging' bindings, the reviewers could say "you are using 'staging' bindings,
please add compatibility with 'staging' and 'standard' bindings", even if that
includes the discussion and review of newly created 'standard' bindings
corresponding to the 'staging' bindings.
- the submitter may even say "there's no need for compatibility for 'staging'
bindings, because they were never used (or other valid reasons)".
What would you think of something like that?
> If, at the end of that, a proprietary vendor driver is using a different
> version of the binding anyway, because "there's no backward
> compatibility to guarantee", then there is no benefit to the document.
No, it would not use a "different version of the binding", because the
binding would be public, i.e.: everything would be on the public DT.
> Even if that proprietary driver does remain stable, the Linux community
> will have done work that only benefits the authors of that driver. We
> would prefer that the results of our efforts are open, and benefit all.
Do you have an example of a binding *not used by Linux* that created enormous
amount of work for the Linux community?
>> I can understand the effort it takes to review a binding and some
>> driver, but if there's no driver, why would it matter if the DT binding is
>> 100% right? Hence, why would it take more effort?
>> Furthermore, if there's no driver, there's no backward compatibility to
>> guarantee. Shouldn't it require less effort?
>
> I don't follow. If there's no compatibility to guarantee, why do you
> want a binding?
Let's make an abstraction of the word 'binding', 'create a binding', etc. and
just focus on this:
- Somebody submits a DT file that contains properties and nodes that are
*not used* by any Linux driver.
- Said properties and nodes serve as HW description for HW blocks for which
*there is no* Linux driver.
The goal of the above is to use the DT as the authoritative (and single)
source of HW definition.
An alternate solution, as proposed by Warner, is to use 'binary overlays' for
the DT.
> A binding is a form of contract -- if you describe the HW this way, then
> some software will understand it. You can extend a binding over time,
> certainly, but if the baseline of that binding is a moving target, that
> benefits nobody.
>
The benefit is that in one case (the case where the whole SoC is described
in the DT, regardless of the existence of a Linux driver or not) there is more
information available publicly.
>> I see, although I don't understand how accepting such solution (i.e.: having the
>> information in a different DT) benefits the open-source community, since it
>> basically means that the open-source community settles for less information.
>
> As with all things, it depends on context. If someone's using a DT to
> describe details of the secure world of a platform with trustzone to a
> secure OS, then not all of that information is relevant to Linux.
> Likewise if configuration details specific to FW are embedded.
Ok, so if the information is not relevant to Linux do you agree that it
should not affect it, and then we could imagine such details being present on
the DT anyway?
> If there's information relevant to a general purpose OS, then I would
> expect it to be described. By the same token, I would expect a general
> purpose OS to actually be making use of the information. In practice,
> we've used Linux as the benchmark for that. That needn't necessarily be
> the case if another OS can demonstrate that the binding is worthwhile --
> ideally we'd have multiple OSs using bindings so as to "keep us honest"
> and free from implementation details.
You mention the case of another OS.
What is the definition of OS in this case?
Because one could say that "FW" or "secure world" could fit that definition,
right?
Or when you talk about "another OS" you think only about other open-source
mainstream OSs, like FreeBSD?
> As I mentioned before, an example would help. The theoretical envelope
> is very large and likely far beyond what you envisage. We need something
> to focus on, or we're arguing about what we conceive differently.
>
I think we've made progress :-)
Indeed, to me it is clear that what we conceive "differently", is that
"the effort", "lack of benefit for the community", "Old bindings should
remain supported regardless" and "backward compatibility" are considered
with respect to DT *plus* driver, yet the idea is to have DT describe
HW for which there's no upstream driver yet.
Hence most of those considerations should not apply, right?
Best regards,
Sebastian
^ permalink raw reply
* [PATCH V5] perf tools: adding support for address filters
From: Adrian Hunter @ 2016-09-13 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473702794-8493-1-git-send-email-mathieu.poirier@linaro.org>
On 12/09/16 20:53, Mathieu Poirier wrote:
> This patch makes it possible to use the current filter
> framework with address filters. That way address filters for
> HW tracers such as CoreSight and IntelPT can be communicated
> to the kernel drivers.
>
> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> ---
> Changes for V5:
> - Modified perf_evsel__append_filter() to take a string format
> rather than an operation.
Hope I'm not being a pain, but aren't there other places calling
perf_evsel__append_filter() that need to be changed. Might make
sense as a separate patch.
>
> Changes for V4:
> - Added support for address filters over more than one
> nibble.
> - Removed Jiri's ack, this version is too different from
> what was reviewed.
>
> Changes for V3:
> - Added Jiri's ack.
> - Rebased to v4.8-rc5.
>
> Changes for V2:
> - Rebased to v4.8-rc4.
> - Revisited error path.
>
>
> tools/perf/util/evsel.c | 4 ++--
> tools/perf/util/evsel.h | 2 +-
> tools/perf/util/parse-events.c | 40 +++++++++++++++++++++++++++++++++++-----
> 3 files changed, 38 insertions(+), 8 deletions(-)
>
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index d40f852d2de2..a9bb277f221f 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -1047,14 +1047,14 @@ int perf_evsel__set_filter(struct perf_evsel *evsel, const char *filter)
> }
>
> int perf_evsel__append_filter(struct perf_evsel *evsel,
> - const char *op, const char *filter)
> + const char *fmt, const char *filter)
> {
> char *new_filter;
>
> if (evsel->filter == NULL)
> return perf_evsel__set_filter(evsel, filter);
>
> - if (asprintf(&new_filter,"(%s) %s (%s)", evsel->filter, op, filter) > 0) {
> + if (asprintf(&new_filter, fmt, evsel->filter, filter) > 0) {
> free(evsel->filter);
> evsel->filter = new_filter;
> return 0;
> diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
> index 8ceb7ebb51f5..50595c8c7207 100644
> --- a/tools/perf/util/evsel.h
> +++ b/tools/perf/util/evsel.h
> @@ -236,7 +236,7 @@ void perf_evsel__set_sample_id(struct perf_evsel *evsel,
>
> int perf_evsel__set_filter(struct perf_evsel *evsel, const char *filter);
> int perf_evsel__append_filter(struct perf_evsel *evsel,
> - const char *op, const char *filter);
> + const char *fmt, const char *filter);
> int perf_evsel__apply_filter(struct perf_evsel *evsel, int ncpus, int nthreads,
> const char *filter);
> int perf_evsel__apply_drv_configs(struct perf_evsel *evsel,
> diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
> index 2eb8b1ed4cc8..8e683979ccd8 100644
> --- a/tools/perf/util/parse-events.c
> +++ b/tools/perf/util/parse-events.c
> @@ -1760,20 +1760,50 @@ foreach_evsel_in_last_glob(struct perf_evlist *evlist,
> static int set_filter(struct perf_evsel *evsel, const void *arg)
> {
> const char *str = arg;
> + bool found = false;
> + int nr_addr_filters = 0;
> + struct perf_pmu *pmu = NULL;
>
> - if (evsel == NULL || evsel->attr.type != PERF_TYPE_TRACEPOINT) {
> - fprintf(stderr,
> - "--filter option should follow a -e tracepoint option\n");
> - return -1;
> + if (evsel == NULL)
> + goto err;
> +
> + if (evsel->attr.type == PERF_TYPE_TRACEPOINT) {
> + if (perf_evsel__append_filter(evsel,
> + "(%s) && (%s)", str) < 0) {
> + fprintf(stderr,
> + "not enough memory to hold filter string\n");
> + return -1;
> + }
> +
> + return 0;
> }
>
> - if (perf_evsel__append_filter(evsel, "&&", str) < 0) {
> + while ((pmu = perf_pmu__scan(pmu)) != NULL)
> + if (pmu->type == evsel->attr.type) {
> + found = true;
> + break;
> + }
> +
> + if (found)
> + perf_pmu__scan_file(pmu, "nr_addr_filters",
> + "%d", &nr_addr_filters);
> +
> + if (!nr_addr_filters)
> + goto err;
> +
> + if (perf_evsel__append_filter(evsel, "%s,%s", str) < 0) {
> fprintf(stderr,
> "not enough memory to hold filter string\n");
> return -1;
> }
>
> return 0;
> +
> +err:
> + fprintf(stderr,
> + "--filter option should follow a -e tracepoint or HW tracer option\n");
> +
> + return -1;
> }
>
> int parse_filter(const struct option *opt, const char *str,
>
^ permalink raw reply
* [PATCH v7 8/9] drm/mediatek: update DSI sub driver flow
From: CK Hu @ 2016-09-13 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473675347.12398.24.camel@mtksdaap41>
Hi, YT:
On Mon, 2016-09-12 at 18:15 +0800, YT Shen wrote:
> Hi CK,
>
> On Wed, 2016-09-07 at 12:58 +0800, CK Hu wrote:
> > Hi, YT:
> >
> > On Fri, 2016-09-02 at 19:24 +0800, YT Shen wrote:
> > > This patch update enable/disable flow of DSI module and MIPI TX module
> > >
> > > Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> > > Signed-off-by: YT Shen <yt.shen@mediatek.com>
> > > ---
> >
> > I think the description is too simple. Please briefly describe WHY of
> > this patch. The original enable/disable flow is workable, so why do you
> > need this patch? Without this patch, what problem would happen?
> Got it, we will update more descriptions in the next version.
> There is no transfer/interrupt function in the upstream DSI driver.
> We also implement the following function [1][2] in this patch series.
>
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
>
> [1] https://patchwork.kernel.org/patch/9310819/
> drm/mediatek: add dsi interrupt control
> [2] https://patchwork.kernel.org/patch/9310823/
> drm/mediatek: add dsi transfer function
>
I suggest you to separate "DSI directly connect to panel" related
patches to another series because MT8173 could also apply it and it is
not essential for MT2701 if MT2701 use bridge IC for dsi.
Regards,
CK
> >
> > Regards,
> > CK
> >
> >
>
>
^ permalink raw reply
* [PATCH v7.1 04/22] iommu: Introduce iommu_fwspec
From: Robin Murphy @ 2016-09-13 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <742a71630de502ac5a7a8641c6ed368d8409324d.1473695704.git.robin.murphy@arm.com>
Introduce a common structure to hold the per-device firmware data that
most IOMMU drivers need to keep track of. This enables us to configure
much of that data from common firmware code, and consolidate a lot of
the equivalent implementations, device look-up tables, etc. which are
currently strewn across IOMMU drivers.
This will also be enable us to address the outstanding "multiple IOMMUs
on the platform bus" problem by tweaking IOMMU API calls to prefer
dev->fwspec->ops before falling back to dev->bus->iommu_ops, and thus
gracefully handle those troublesome systems which we currently cannot.
As the first user, hook up the OF IOMMU configuration mechanism. The
driver-defined nature of DT cells means that we still need the drivers
to translate and add the IDs themselves, but future users such as the
much less free-form ACPI IORT will be much simpler and self-contained.
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
- Drop the 'gradual introduction' fiddling and go straight to struct
device and common code, as it prevents all the silly build issues
and ultimately makes life simpler for everyone
- This time without missing "static inline"s on the stubs...
---
drivers/iommu/iommu.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++
drivers/iommu/of_iommu.c | 8 +++++--
include/linux/device.h | 3 +++
include/linux/iommu.h | 39 ++++++++++++++++++++++++++++++++
4 files changed, 106 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index b06d93594436..9a2f1960873b 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -31,6 +31,7 @@
#include <linux/err.h>
#include <linux/pci.h>
#include <linux/bitops.h>
+#include <linux/property.h>
#include <trace/events/iommu.h>
static struct kset *iommu_group_kset;
@@ -1613,3 +1614,60 @@ out:
return ret;
}
+
+int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
+ const struct iommu_ops *ops)
+{
+ struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+ if (fwspec)
+ return ops == fwspec->ops ? 0 : -EINVAL;
+
+ fwspec = kzalloc(sizeof(*fwspec), GFP_KERNEL);
+ if (!fwspec)
+ return -ENOMEM;
+
+ of_node_get(to_of_node(iommu_fwnode));
+ fwspec->iommu_fwnode = iommu_fwnode;
+ fwspec->ops = ops;
+ dev->iommu_fwspec = fwspec;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(iommu_fwspec_init);
+
+void iommu_fwspec_free(struct device *dev)
+{
+ struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+ if (fwspec) {
+ fwnode_handle_put(fwspec->iommu_fwnode);
+ kfree(fwspec);
+ dev->iommu_fwspec = NULL;
+ }
+}
+EXPORT_SYMBOL_GPL(iommu_fwspec_free);
+
+int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
+{
+ struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+ size_t size;
+ int i;
+
+ if (!fwspec)
+ return -EINVAL;
+
+ size = offsetof(struct iommu_fwspec, ids[fwspec->num_ids + num_ids]);
+ if (size > sizeof(*fwspec)) {
+ fwspec = krealloc(dev->iommu_fwspec, size, GFP_KERNEL);
+ if (!fwspec)
+ return -ENOMEM;
+ }
+
+ for (i = 0; i < num_ids; i++)
+ fwspec->ids[fwspec->num_ids + i] = ids[i];
+
+ fwspec->num_ids += num_ids;
+ dev->iommu_fwspec = fwspec;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(iommu_fwspec_add_ids);
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 19e1e8f2f871..5b82862f571f 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -167,7 +167,9 @@ static const struct iommu_ops
return NULL;
ops = of_iommu_get_ops(iommu_spec.np);
- if (!ops || !ops->of_xlate || ops->of_xlate(&pdev->dev, &iommu_spec))
+ if (!ops || !ops->of_xlate ||
+ iommu_fwspec_init(&pdev->dev, &iommu_spec.np->fwnode, ops) ||
+ ops->of_xlate(&pdev->dev, &iommu_spec))
ops = NULL;
of_node_put(iommu_spec.np);
@@ -196,7 +198,9 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
np = iommu_spec.np;
ops = of_iommu_get_ops(np);
- if (!ops || !ops->of_xlate || ops->of_xlate(dev, &iommu_spec))
+ if (!ops || !ops->of_xlate ||
+ iommu_fwspec_init(dev, &np->fwnode, ops) ||
+ ops->of_xlate(dev, &iommu_spec))
goto err_put_node;
of_node_put(np);
diff --git a/include/linux/device.h b/include/linux/device.h
index 38f02814d53a..bc41e87a969b 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -41,6 +41,7 @@ struct device_node;
struct fwnode_handle;
struct iommu_ops;
struct iommu_group;
+struct iommu_fwspec;
struct bus_attribute {
struct attribute attr;
@@ -765,6 +766,7 @@ struct device_dma_parameters {
* gone away. This should be set by the allocator of the
* device (i.e. the bus driver that discovered the device).
* @iommu_group: IOMMU group the device belongs to.
+ * @iommu_fwspec: IOMMU-specific properties supplied by firmware.
*
* @offline_disabled: If set, the device is permanently online.
* @offline: Set after successful invocation of bus type's .offline().
@@ -849,6 +851,7 @@ struct device {
void (*release)(struct device *dev);
struct iommu_group *iommu_group;
+ struct iommu_fwspec *iommu_fwspec;
bool offline_disabled:1;
bool offline:1;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index a35fb8b42e1a..436dc21318af 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -331,10 +331,32 @@ extern struct iommu_group *pci_device_group(struct device *dev);
/* Generic device grouping function */
extern struct iommu_group *generic_device_group(struct device *dev);
+/**
+ * struct iommu_fwspec - per-device IOMMU instance data
+ * @ops: ops for this device's IOMMU
+ * @iommu_fwnode: firmware handle for this device's IOMMU
+ * @iommu_priv: IOMMU driver private data for this device
+ * @num_ids: number of associated device IDs
+ * @ids: IDs which this device may present to the IOMMU
+ */
+struct iommu_fwspec {
+ const struct iommu_ops *ops;
+ struct fwnode_handle *iommu_fwnode;
+ void *iommu_priv;
+ unsigned int num_ids;
+ u32 ids[1];
+};
+
+int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
+ const struct iommu_ops *ops);
+void iommu_fwspec_free(struct device *dev);
+int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
+
#else /* CONFIG_IOMMU_API */
struct iommu_ops {};
struct iommu_group {};
+struct iommu_fwspec {};
static inline bool iommu_present(struct bus_type *bus)
{
@@ -541,6 +563,23 @@ static inline void iommu_device_unlink(struct device *dev, struct device *link)
{
}
+static inline int iommu_fwspec_init(struct device *dev,
+ struct fwnode_handle *iommu_fwnode,
+ const struct iommu_ops *ops)
+{
+ return -ENODEV;
+}
+
+static inline void iommu_fwspec_free(struct device *dev)
+{
+}
+
+static inline int iommu_fwspec_add_ids(struct device *dev, u32 *ids,
+ int num_ids)
+{
+ return -ENODEV;
+}
+
#endif /* CONFIG_IOMMU_API */
#endif /* __LINUX_IOMMU_H */
--
2.8.1.dirty
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: imx6ul: Add DTS for liteBoard
From: Marcin Niestroj @ 2016-09-13 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913094951.26394-1-m.niestroj@grinn-global.com>
liteBoard is a development board which uses liteSOM as its base.
Hardware specification:
* liteSOM (i.MX6UL, DRAM, eMMC)
* Ethernet PHY (id 0)
* USB host (usb_otg1)
* MicroSD slot (uSDHC1)
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
---
Changes v1 -> v2:
* Use dual license
* Fix typo "defaullt" -> "default"
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6ul-liteboard.dts | 153 +++++++++++++++++++++++++++++++++
2 files changed, 154 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-liteboard.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index faacd52..b149313 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -407,6 +407,7 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
imx6sx-sdb.dtb
dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-14x14-evk.dtb \
+ imx6ul-liteboard.dtb \
imx6ul-pico-hobbit.dtb \
imx6ul-tx6ul-0010.dtb \
imx6ul-tx6ul-0011.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-liteboard.dts b/arch/arm/boot/dts/imx6ul-liteboard.dts
new file mode 100644
index 0000000..f2e04f2
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-liteboard.dts
@@ -0,0 +1,153 @@
+/*
+ * Copyright 2016 Grinn
+ *
+ * Author: Marcin Niestroj <m.niestroj@grinn-global.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (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 , 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.
+ */
+
+/dts-v1/;
+
+#include "imx6ul-litesom.dtsi"
+
+/ {
+ model = "Grinn i.MX6UL liteBoard";
+ compatible = "grinn,imx6ul-liteboard", "grinn,imx6ul-litesom",
+ "fsl,imx6ul";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_usb_otg1_vbus: usb_otg1_regulator {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_otg1_vbus>;
+ regulator-name = "usb_otg1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio2 8 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&iomuxc {
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
+ MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x1b0b0
+ MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0
+ MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x17059
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10071
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
+ >;
+ };
+
+ pinctrl_usb_otg1_vbus: usb_otg1_vbus {
+ fsl,pins = <
+ MX6UL_PAD_ENET2_RX_DATA0__GPIO2_IO08 0x79
+ >;
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet1>;
+ phy-mode = "rmii";
+ phy-handle = <ðphy0>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy at 0 {
+ reg = <0>;
+ };
+ };
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&usbotg1 {
+ vbus-supply = <®_usb_otg1_vbus>;
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ keep-power-in-suspend;
+ wakeup-source;
+ status = "okay";
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/2] ARM: dts: imx6ul: Add DTS for liteSOM module
From: Marcin Niestroj @ 2016-09-13 9:49 UTC (permalink / raw)
To: linux-arm-kernel
This is a SOM (System on Module), so it will be part of another boards.
Hence, this is a "dtsi" file that will be included from another device
tree files.
Hardware specification:
* Freescale i.MX6UL SoC
* up to 512 MB RAM
* eMMC on uSDHC2
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
---
Changes v1 -> v2:
* Use dual license
arch/arm/boot/dts/imx6ul-litesom.dtsi | 87 +++++++++++++++++++++++++++++++++++
1 file changed, 87 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-litesom.dtsi
diff --git a/arch/arm/boot/dts/imx6ul-litesom.dtsi b/arch/arm/boot/dts/imx6ul-litesom.dtsi
new file mode 100644
index 0000000..c0345b4
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-litesom.dtsi
@@ -0,0 +1,87 @@
+/*
+ * Copyright 2016 Grinn
+ *
+ * Author: Marcin Niestroj <m.niestroj@grinn-global.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (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 , 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.
+ */
+
+#include "imx6ul.dtsi"
+
+/ {
+ model = "Grinn i.MX6UL liteSOM";
+ compatible = "grinn,imx6ul-litesom", "fsl,imx6ul";
+
+ memory {
+ reg = <0x80000000 0x20000000>;
+ };
+};
+
+&cpu0 {
+ arm-supply = <®_arm>;
+ soc-supply = <®_soc>;
+};
+
+&iomuxc {
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x10069
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x17059
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x17059
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x17059
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x17059
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x17059
+ MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x17059
+ MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x17059
+ MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x17059
+ MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x17059
+ MX6UL_PAD_NAND_ALE__USDHC2_RESET_B 0x17059
+ >;
+ };
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ no-1-8-v;
+ non-removable;
+ keep-power-in-suspend;
+ wakeup-source;
+ bus-width = <8>;
+ status = "okay";
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v8 4/9] drm/mediatek: update display module connections
From: CK Hu @ 2016-09-13 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473681672-47144-5-git-send-email-yt.shen@mediatek.com>
Hi, YT:
On Mon, 2016-09-12 at 20:01 +0800, YT Shen wrote:
> update connections for OVL, RDMA, BLS, DSI
>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
[snip...]
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 53065c7..0850aa4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -40,6 +40,7 @@ enum mtk_ddp_comp_type {
>
> enum mtk_ddp_comp_id {
> DDP_COMPONENT_AAL,
> + DDP_COMPONENT_BLS,
I think this should be moved to an independent patch and title of it
should be "Add BLS component." If you keep it in this patch, title of
this patch should be modified as "Add BLS component and update display
module connections."
Regards,
CK
> DDP_COMPONENT_COLOR0,
> DDP_COMPONENT_COLOR1,
> DDP_COMPONENT_DPI0,
^ permalink raw reply
* [PATCHv3 06/11] crypto: omap-des: Fix support for unequal lengths
From: Herbert Xu @ 2016-09-13 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1470306526-27219-7-git-send-email-t-kristo@ti.com>
On Thu, Aug 04, 2016 at 01:28:41PM +0300, Tero Kristo wrote:
> From: Lokesh Vutla <a0131933@ti.com>
>
> For cases where total length of an input SGs is not same as
> length of the input data for encryption, omap-des driver
> crashes. This happens in the case when IPsec is trying to use
> omap-des driver.
>
> To avoid this, we copy all the pages from the input SG list
> into a contiguous buffer and prepare a single element SG list
> for this buffer with length as the total bytes to crypt, which is
> similar thing that is done in case of unaligned lengths.
Ugh, that means copying every single packet, right?
So if it's just the SG list that's the problem, why don't you
copy that instead? That is, allocate a new SG list and set it
up so that there is no excess data.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH V5 6/6] ARM64: bcm2835: add thermal driver to default_config
From: kernel at martin.sperl.org @ 2016-09-13 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473759262-27031-1-git-send-email-kernel@martin.sperl.org>
From: Martin Sperl <kernel@martin.sperl.org>
Add the thermal driver for bcm2837 to list of compiled modules
in the default config.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
Note: untested as I have no 64 bit test system.
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index eadf485..372f981 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -252,6 +252,7 @@ CONFIG_SENSORS_INA2XX=m
CONFIG_SENSORS_ARM_SCPI=y
CONFIG_THERMAL=y
CONFIG_THERMAL_EMULATION=y
+CONFIG_BCM2835_THERMAL=y
CONFIG_EXYNOS_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_RENESAS_WDT=y
--
2.1.4
^ permalink raw reply related
* [PATCH V5 5/6] ARM: bcm2835: add thermal driver to default_config
From: kernel at martin.sperl.org @ 2016-09-13 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473759262-27031-1-git-send-email-kernel@martin.sperl.org>
From: Martin Sperl <kernel@martin.sperl.org>
Add the thermal driver to list of compiled modules
in the default config for bcm2835.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
---
arch/arm/configs/bcm2835_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 79de828..4b89f4e 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -73,6 +73,8 @@ CONFIG_SPI_BCM2835=y
CONFIG_SPI_BCM2835AUX=y
CONFIG_GPIO_SYSFS=y
# CONFIG_HWMON is not set
+CONFIG_THERMAL=y
+CONFIG_BCM2835_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_BCM2835_WDT=y
CONFIG_DRM=y
--
2.1.4
^ permalink raw reply related
* [PATCH V5 4/6] ARM64: bcm2835: dts: add thermal node to device-tree of bcm2837
From: kernel at martin.sperl.org @ 2016-09-13 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473759262-27031-1-git-send-email-kernel@martin.sperl.org>
From: Martin Sperl <kernel@martin.sperl.org>
Add the node for the thermal sensor of the bcm2837-soc
to the device tree.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
---
arch/arm64/boot/dts/broadcom/bcm2837.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
Note: untested as I have no 64 bit test system.
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
index f2a31d0..2b0cfc7 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
@@ -74,3 +74,9 @@
interrupt-parent = <&local_intc>;
interrupts = <8>;
};
+
+/* enable thermal sensor with the correct compatible property set */
+&thermal {
+ compatible = "brcm,bcm2837-thermal";
+ status = "okay";
+};
--
2.1.4
^ permalink raw reply related
* [PATCH V5 3/6] ARM: bcm2835: dts: add thermal node to device-tree of bcm283x
From: kernel at martin.sperl.org @ 2016-09-13 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473759262-27031-1-git-send-email-kernel@martin.sperl.org>
From: Martin Sperl <kernel@martin.sperl.org>
Add the node for the thermal sensor of the bcm2835-soc
to the device tree.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Changelog:
V1 -> V5: generic settings is shared in bcm283x.dtsi, but disabled
moved the compatible string to the SOC specific dtsi
for arm and arm64
Note: there is no arm/boot/dts/bcm2837.dtsi as of now,
so there is no support for bcm2837 in 32 bit mode.
---
arch/arm/boot/dts/bcm2835.dtsi | 6 ++++++
arch/arm/boot/dts/bcm2836.dtsi | 6 ++++++
arch/arm/boot/dts/bcm283x.dtsi | 7 +++++++
3 files changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index a78759e..0890d97 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -23,3 +23,9 @@
};
};
};
+
+/* enable thermal sensor with the correct compatible property set */
+&thermal {
+ compatible = "brcm,bcm2835-thermal";
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/bcm2836.dtsi b/arch/arm/boot/dts/bcm2836.dtsi
index 9d0651d..519a44f 100644
--- a/arch/arm/boot/dts/bcm2836.dtsi
+++ b/arch/arm/boot/dts/bcm2836.dtsi
@@ -76,3 +76,9 @@
interrupt-parent = <&local_intc>;
interrupts = <8>;
};
+
+/* enable thermal sensor with the correct compatible property set */
+&thermal {
+ compatible = "brcm,bcm2836-thermal";
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index b982522..2cc4847 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -186,6 +186,13 @@
interrupts = <2 14>; /* pwa1 */
};
+ thermal: thermal at 0x7e212000 {
+ compatible = "brcm,bcm2835-thermal";
+ reg = <0x7e212000 0x8>;
+ clocks = <&clocks BCM2835_CLOCK_TSENS>;
+ status = "disabled";
+ };
+
aux: aux at 0x7e215000 {
compatible = "brcm,bcm2835-aux";
#clock-cells = <1>;
--
2.1.4
^ permalink raw reply related
* [PATCH V5 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: kernel at martin.sperl.org @ 2016-09-13 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473759262-27031-1-git-send-email-kernel@martin.sperl.org>
From: Martin Sperl <kernel@martin.sperl.org>
Add basic thermal driver for bcm2835 SOC.
This driver currently relies on the firmware setting up the
tsense HW block and does not set it up itself.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
ChangeLog:
V1 -> V2: added specific settings depending on compatiblity
added trip point based on register
setting up ctrl-register if HW is not enabled by firmware
as per recommendation of Eric (untested)
check that clock frequency is in range
(1.9 - 5MHz - as per comment in clk-bcm2835.c)
V2 -> V4: moved back to thermal (not using bcm sub-directory)
set polling interval to 1second (was 0ms, so interrupt driven)
---
drivers/thermal/Kconfig | 5 +
drivers/thermal/Makefile | 1 +
drivers/thermal/bcm2835_thermal.c | 327 ++++++++++++++++++++++++++++++++++++++
3 files changed, 333 insertions(+)
create mode 100644 drivers/thermal/bcm2835_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 2d702ca..5e3e4e4 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -399,4 +399,9 @@ config GENERIC_ADC_THERMAL
to this driver. This driver reports the temperature by reading ADC
channel and converts it to temperature based on lookup table.
+config BCM2835_THERMAL
+ tristate "Thermal sensors on bcm2835 SoC"
+ help
+ Support for thermal sensors on Broadcom bcm2835 SoCs.
+
endif
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 10b07c1..c26343e 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -51,3 +51,4 @@ obj-$(CONFIG_TEGRA_SOCTHERM) += tegra/
obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o
obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
+obj-$(CONFIG_BCM2835_THERMAL) += bcm2835_thermal.o
diff --git a/drivers/thermal/bcm2835_thermal.c b/drivers/thermal/bcm2835_thermal.c
new file mode 100644
index 0000000..6fa972e
--- /dev/null
+++ b/drivers/thermal/bcm2835_thermal.c
@@ -0,0 +1,327 @@
+/*
+ * Driver for Broadcom BCM2835 soc temperature sensor
+ *
+ * Copyright (C) 2016 Martin Sperl
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/debugfs.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/thermal.h>
+
+#define BCM2835_TS_TSENSCTL 0x00
+#define BCM2835_TS_TSENSSTAT 0x04
+
+#define BCM2835_TS_TSENSCTL_PRWDW BIT(0)
+#define BCM2835_TS_TSENSCTL_RSTB BIT(1)
+#define BCM2835_TS_TSENSCTL_CTRL_BITS 3
+#define BCM2835_TS_TSENSCTL_CTRL_SHIFT 2
+#define BCM2835_TS_TSENSCTL_CTRL_MASK \
+ GENMASK(BCM2835_TS_TSENSCTL_CTRL_BITS + \
+ BCM2835_TS_TSENSCTL_CTRL_SHIFT - 1, \
+ BCM2835_TS_TSENSCTL_CTRL_SHIFT)
+#define BCM2835_TS_TSENSCTL_CTRL_DEFAULT 1
+#define BCM2835_TS_TSENSCTL_EN_INT BIT(5)
+#define BCM2835_TS_TSENSCTL_DIRECT BIT(6)
+#define BCM2835_TS_TSENSCTL_CLR_INT BIT(7)
+#define BCM2835_TS_TSENSCTL_THOLD_SHIFT 8
+#define BCM2835_TS_TSENSCTL_THOLD_BITS 10
+#define BCM2835_TS_TSENSCTL_THOLD_MASK \
+ GENMASK(BCM2835_TS_TSENSCTL_THOLD_BITS + \
+ BCM2835_TS_TSENSCTL_THOLD_SHIFT - 1, \
+ BCM2835_TS_TSENSCTL_THOLD_SHIFT)
+#define BCM2835_TS_TSENSCTL_RSTDELAY_SHIFT 18
+#define BCM2835_TS_TSENSCTL_RSTDELAY_BITS 8
+#define BCM2835_TS_TSENSCTL_RSTDELAY_DEFAULT 14
+#define BCM2835_TS_TSENSCTL_REGULEN BIT(26)
+
+#define BCM2835_TS_TSENSSTAT_DATA_BITS 10
+#define BCM2835_TS_TSENSSTAT_DATA_SHIFT 0
+#define BCM2835_TS_TSENSSTAT_DATA_MASK \
+ GENMASK(BCM2835_TS_TSENSSTAT_DATA_BITS + \
+ BCM2835_TS_TSENSSTAT_DATA_SHIFT - 1, \
+ BCM2835_TS_TSENSSTAT_DATA_SHIFT)
+#define BCM2835_TS_TSENSSTAT_VALID BIT(10)
+#define BCM2835_TS_TSENSSTAT_INTERRUPT BIT(11)
+
+struct bcm2835_thermal_info {
+ int offset;
+ int slope;
+ int trip_temp;
+};
+
+struct bcm2835_thermal_data {
+ const struct bcm2835_thermal_info *info;
+ void __iomem *regs;
+ struct clk *clk;
+ struct dentry *debugfsdir;
+};
+
+static int bcm2835_thermal_adc2temp(
+ const struct bcm2835_thermal_info *info, u32 adc)
+{
+ return info->offset + (adc * info->slope);
+}
+
+static int bcm2835_thermal_temp2adc(
+ const struct bcm2835_thermal_info *info, int temp)
+{
+ temp -= info->offset;
+ temp /= info->slope;
+
+ if (temp < 0)
+ temp = 0;
+ if (temp >= BIT(BCM2835_TS_TSENSSTAT_DATA_BITS))
+ temp = BIT(BCM2835_TS_TSENSSTAT_DATA_BITS) - 1;
+
+ return temp;
+}
+
+static int bcm2835_thermal_get_trip_type(
+ struct thermal_zone_device *tz, int trip,
+ enum thermal_trip_type *type)
+{
+ *type = THERMAL_TRIP_CRITICAL;
+ return 0;
+}
+
+static int bcm2835_thermal_get_trip_temp(
+ struct thermal_zone_device *tz, int trip, int *temp)
+{
+ struct bcm2835_thermal_data *data = tz->devdata;
+ u32 val = readl(data->regs + BCM2835_TS_TSENSCTL);
+
+ /* get the THOLD bits */
+ val &= BCM2835_TS_TSENSCTL_THOLD_MASK;
+ val >>= BCM2835_TS_TSENSCTL_THOLD_SHIFT;
+
+ /* if it is zero then use the info value */
+ if (val)
+ *temp = bcm2835_thermal_adc2temp(data->info, val);
+ else
+ *temp = data->info->trip_temp;
+
+ return 0;
+}
+
+static int bcm2835_thermal_get_temp(struct thermal_zone_device *tz,
+ int *temp)
+{
+ struct bcm2835_thermal_data *data = tz->devdata;
+ u32 val = readl(data->regs + BCM2835_TS_TSENSSTAT);
+
+ if (!(val & BCM2835_TS_TSENSSTAT_VALID))
+ return -EIO;
+
+ /* mask the relevant bits */
+ val &= BCM2835_TS_TSENSSTAT_DATA_MASK;
+
+ *temp = bcm2835_thermal_adc2temp(data->info, val);
+
+ return 0;
+}
+
+static const struct debugfs_reg32 bcm2835_thermal_regs[] = {
+ {
+ .name = "ctl",
+ .offset = 0
+ },
+ {
+ .name = "stat",
+ .offset = 4
+ }
+};
+
+static void bcm2835_thermal_debugfs(struct platform_device *pdev)
+{
+ struct thermal_zone_device *tz = platform_get_drvdata(pdev);
+ struct bcm2835_thermal_data *data = tz->devdata;
+ struct debugfs_regset32 *regset;
+
+ data->debugfsdir = debugfs_create_dir("bcm2835_thermal", NULL);
+ if (!data->debugfsdir)
+ return;
+
+ regset = devm_kzalloc(&pdev->dev, sizeof(*regset), GFP_KERNEL);
+ if (!regset)
+ return;
+
+ regset->regs = bcm2835_thermal_regs;
+ regset->nregs = ARRAY_SIZE(bcm2835_thermal_regs);
+ regset->base = data->regs;
+
+ debugfs_create_regset32("regset", S_IRUGO,
+ data->debugfsdir, regset);
+}
+
+static struct thermal_zone_device_ops bcm2835_thermal_ops = {
+ .get_temp = bcm2835_thermal_get_temp,
+ .get_trip_temp = bcm2835_thermal_get_trip_temp,
+ .get_trip_type = bcm2835_thermal_get_trip_type,
+};
+
+static const struct of_device_id bcm2835_thermal_of_match_table[];
+static int bcm2835_thermal_probe(struct platform_device *pdev)
+{
+ const struct of_device_id *match;
+ struct thermal_zone_device *tz;
+ struct bcm2835_thermal_data *data;
+ struct resource *res;
+ int err;
+ u32 val;
+ unsigned long rate;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ match = of_match_device(bcm2835_thermal_of_match_table,
+ &pdev->dev);
+ if (!match)
+ return -EINVAL;
+ data->info = match->data;
+
+ /* get registers */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ data->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(data->regs)) {
+ err = PTR_ERR(data->regs);
+ dev_err(&pdev->dev, "Could not get registers: %d\n", err);
+ return err;
+ }
+
+ /* get clock */
+ data->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(data->clk)) {
+ err = PTR_ERR(data->clk);
+ if (err != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "Could not get clk: %d\n", err);
+ return err;
+ }
+
+ /* set up registers if not already done by the fw */
+ val = readl(data->regs + BCM2835_TS_TSENSCTL);
+ if (!(val & BCM2835_TS_TSENSCTL_RSTB)) {
+ /* the basic required flags */
+ val = (BCM2835_TS_TSENSCTL_CTRL_DEFAULT <<
+ BCM2835_TS_TSENSCTL_CTRL_SHIFT) |
+ BCM2835_TS_TSENSCTL_REGULEN;
+
+ /* reset delay */
+ val |= (BCM2835_TS_TSENSCTL_RSTDELAY_DEFAULT <<
+ BCM2835_TS_TSENSCTL_RSTDELAY_SHIFT);
+
+ /* trip_adc value from info */
+ val |= bcm2835_thermal_temp2adc(data->info,
+ data->info->trip_temp) <<
+ BCM2835_TS_TSENSCTL_THOLD_SHIFT;
+
+ /* write the value back to the register as 2 steps */
+ writel(val, data->regs + BCM2835_TS_TSENSCTL);
+ val |= BCM2835_TS_TSENSCTL_RSTB;
+ writel(val, data->regs + BCM2835_TS_TSENSCTL);
+ }
+
+ /* enable clock and check rate */
+ clk_prepare_enable(data->clk);
+ rate = clk_get_rate(data->clk);
+ if ((rate < 1920000) || (rate > 5000000)) {
+ dev_warn(&pdev->dev,
+ "Clock %pCn is running at %pCr Hz, which is outside the recommended range of 1.9 to 5.0 MHz\n",
+ data->clk, data->clk);
+ }
+
+ /* register thermal zone with 1 trip point an 1s polling */
+ tz = thermal_zone_device_register("bcm2835_thermal",
+ 1, 0, data,
+ &bcm2835_thermal_ops,
+ NULL,
+ 0, 1000);
+ if (IS_ERR(tz)) {
+ clk_disable_unprepare(data->clk);
+ err = PTR_ERR(tz);
+ dev_err(&pdev->dev,
+ "Failed to register the thermal device: %d\n",
+ err);
+ return err;
+ }
+
+ platform_set_drvdata(pdev, tz);
+
+ bcm2835_thermal_debugfs(pdev);
+
+ return 0;
+}
+
+static int bcm2835_thermal_remove(struct platform_device *pdev)
+{
+ struct thermal_zone_device *tz = platform_get_drvdata(pdev);
+ struct bcm2835_thermal_data *data = tz->devdata;
+
+ debugfs_remove_recursive(data->debugfsdir);
+ thermal_zone_device_unregister(tz);
+
+ return 0;
+}
+
+static const struct of_device_id bcm2835_thermal_of_match_table[] = {
+ {
+ .compatible = "brcm,bcm2835-thermal",
+ .data = &(struct bcm2835_thermal_info) {
+ .offset = 407000,
+ .slope = -538,
+ .trip_temp = 80000
+ }
+ },
+ {
+ .compatible = "brcm,bcm2836-thermal",
+ .data = &(struct bcm2835_thermal_info) {
+ .offset = 407000,
+ .slope = -538,
+ .trip_temp = 80000
+ }
+ },
+ {
+ .compatible = "brcm,bcm2837-thermal",
+ .data = &(struct bcm2835_thermal_info) {
+ /* the bcm2837 needs adjustment of +5C */
+ .offset = 407000 + 5000,
+ .slope = -538,
+ .trip_temp = 80000
+ }
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, bcm2835_thermal_of_match_table);
+
+static struct platform_driver bcm2835_thermal_driver = {
+ .probe = bcm2835_thermal_probe,
+ .remove = bcm2835_thermal_remove,
+ .driver = {
+ .name = "bcm2835_thermal",
+ .of_match_table = bcm2835_thermal_of_match_table,
+ },
+};
+module_platform_driver(bcm2835_thermal_driver);
+
+MODULE_AUTHOR("Martin Sperl");
+MODULE_DESCRIPTION("Thermal driver for bcm2835 chip");
+MODULE_LICENSE("GPL");
--
2.1.4
^ permalink raw reply related
* [PATCH V5 1/6] dt: bindings: add thermal device driver for bcm2835
From: kernel at martin.sperl.org @ 2016-09-13 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473759262-27031-1-git-send-email-kernel@martin.sperl.org>
From: Martin Sperl <kernel@martin.sperl.org>
Add dt-binding documentation for bcm2835 SOC thermal sensor.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Acked-by: Eric Anholt <eric@anholt.net>
Acked-by: Rob Herring <robh@kernel.org>
Changelog:
V1 -> V2: renamed file to follow naming conventions
V2 -> V3: removed 0x in node name
---
.../bindings/thermal/brcm,bcm2835-thermal.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt
new file mode 100644
index 0000000..474531d
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt
@@ -0,0 +1,17 @@
+Binding for Thermal Sensor driver for BCM2835 SoCs.
+
+Required parameters:
+-------------------
+
+compatible: should be one of: "brcm,bcm2835-thermal",
+ "brcm,bcm2836-thermal" or "brcm,bcm2837-thermal"
+reg: Address range of the thermal registers.
+clocks: Phandle of the clock used by the thermal sensor.
+
+Example:
+
+thermal: thermal at 7e212000 {
+ compatible = "brcm,bcm2835-thermal";
+ reg = <0x7e212000 0x8>;
+ clocks = <&clocks BCM2835_CLOCK_TSENS>;
+};
--
2.1.4
^ permalink raw reply related
* [PATCH V5 0/6] thermal: bcm2835: add thermal driver
From: kernel at martin.sperl.org @ 2016-09-13 9:34 UTC (permalink / raw)
To: linux-arm-kernel
From: Martin Sperl <kernel@martin.sperl.org>
Add a thermal driver for the TSENSE device of the bcm2835/6/7 SOC.
If the firmware enables the HW, then the configuration is not touched.
In case the firmware has not enabled the device, then we try to set
it up correctly (which unfortunately can not get tested).
It exposes temperature and a critical trip point
(using a hardcoded default of 80C or the temperature configured
in the control register by the firmware, which reads as
407C currently)
The calibrations are (potentially) different for bcm2835, bcm2836
and bcm2837 and can get selected by the compatible property
in the device tree.
The driver also exposes the registers via debugfs.
Possible future enhancements:
* the device has the ability to trigger interrupts on reaching
the programmed critical temperature.
I have no knowledge which interrupt could be responsible
for this on the ARM side, so if we get to know which irq
it is we can implement that.
Instead the driver right now implements polling in 1 second intervals
* the device can also reset the HW after the trip point
has been reached (also with some delay, so that corrective
actions can get taken) - this is currently not enabled by the
firmware, but could.
* we could define more trip points for THERMAL_TRIP_HOT
* make the trip point limits modifiable (ops.set_trip_temp)
Note:
No support for 32-bit arm bcm2837, as there is no
arch/arm/boot/dts/bcm2836.dtsi upstream as of now.
64-bit arm support is not tested
Changelog:
V1 -> V2: renamed dt-binding documentation file
added specific settings depending on compatible
added trip point based on register
setting up ctrl-register if HW is not enabled by firmware
as per recommendation of Eric (untested)
check that clock frequency is in range
(1.9 - 5MHz - as per comment in clk-bcm2835.c)
added driver to multi_v7_defconfig
V2 -> V3: made a module in multi_v7_defconfig
fixed typo in dt-binding document
V3 -> V4: moved driver back to thermal (not using bcm sub-directory)
set polling interval to 1second (was 0ms, so interrupt driven)
V4 -> V5: use correct compatiblity for different soc versions in dt
support ARM64 for bcm2837 in devicetree and defconfig
Martin Sperl (6):
dt: bindings: add thermal device driver for bcm2835
thermal: bcm2835: add thermal driver for bcm2835 soc
ARM: bcm2835: dts: add thermal node to device-tree of bcm283x
ARM64: bcm2835: dts: add thermal node to device-tree of bcm2837
ARM: bcm2835: add thermal driver to default_config
ARM64: bcm2835: add thermal driver to default_config
.../bindings/thermal/brcm,bcm2835-thermal.txt | 17 ++
arch/arm/boot/dts/bcm2835.dtsi | 6 +
arch/arm/boot/dts/bcm2836.dtsi | 6 +
arch/arm/boot/dts/bcm283x.dtsi | 7 +
arch/arm/configs/bcm2835_defconfig | 2 +
arch/arm64/boot/dts/broadcom/bcm2837.dtsi | 6 +
arch/arm64/configs/defconfig | 1 +
drivers/thermal/Kconfig | 5 +
drivers/thermal/Makefile | 1 +
drivers/thermal/bcm2835_thermal.c | 327 +++++++++++++++++++++
10 files changed, 378 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt
create mode 100644 drivers/thermal/bcm2835_thermal.c
--
2.1.4
^ permalink raw reply
* [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
From: Peter Griffin @ 2016-09-13 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473081421-16555-1-git-send-email-peter.griffin@linaro.org>
Hi Vinod & Bjorn,
[..]
On Mon, 05 Sep 2016, Peter Griffin wrote:
> v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
> a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
> slim_rproc driver. The series has also been rebased on v4.8-rc3.
>
> v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
> was found during testing now that the platform boots without clk_ignore_unused parameter
> whereby the clocks would not be enabled properly before firmware loading was attempted.
>
> regards,
>
> Peter.
>
> Changes since v8:
> - Add MODULE_ALIAS (Vinod)
> - devm_kzalloc to devm_kcalloc (Vinod)
> - quisce tasklet initialised by vchan_init() (Vinod)
> - Don't make SLIM rproc user selectable (Bjorn)
> - slim_rproc: Ensure clocks enabled before firmware load (Peter)
> - Various code style nits / commit message change (Lee)
> - Separate patch for '\n' kconfig removal (Vinod)
I hate to send a ping, but do you think we can merge this fdma series? It has gone
through quite a few review rounds now.
regards,
Peter.
^ permalink raw reply
* [RFC PATCH 0/5] arm64: Signal context expansion
From: Florian Weimer @ 2016-09-13 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912153015.GD3958@e103592.cambridge.arm.com>
On 09/12/2016 05:30 PM, Dave Martin wrote:
> On Mon, Sep 12, 2016 at 04:01:17PM +0100, Szabolcs Nagy wrote:
>> i assume the kernel can avoid saving SVE regs when
>> they are not used by the process.
>
> I can (and do), in my patches (not posted yet).
>
> The real issue here is that a recently updated shared library might be
> optimised to use SVE, where the program using it is an older, SVE-
> unaware binary.
>
> (think of an optimised math library using some new fancy SVE-based
> number crunching internally).
In my little world, binaries are expected to do run-time CPU feature
discovery and fall back to the baseline ABI if the system does not
support ABI extensions. This means that a personality flag can disable
the extension, the optimized math libraries run with the slower baseline
code instead, and the rest of the application sees the expected kernel
interface.
From this perspective, it is quite important that it is possible to get
legacy applications running on newer hardware, preferably with out
wrapping them in a dedicated VM.
I understand that there are other environments were this is less of a
concern, but I also believe that the age of an architecture factors less
into this than one might want.
Thanks,
Florian
^ permalink raw reply
* [PATCH v7 7/9] drm/mediatek: add dsi transfer function
From: CK Hu @ 2016-09-13 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473675381.12398.27.camel@mtksdaap41>
Hi, YT:
On Mon, 2016-09-12 at 18:16 +0800, YT Shen wrote:
> Hi CK,
>
> On Wed, 2016-09-07 at 10:33 +0800, CK Hu wrote:
> > Hi, YT:
> >
> > On Fri, 2016-09-02 at 19:24 +0800, YT Shen wrote:
> > > From: shaoming chen <shaoming.chen@mediatek.com>
> > >
> > > add dsi read/write commands for transfer function
> > >
> > > Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_dsi.c | 188 +++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 188 insertions(+)
> > >
> >
> > [snip...]
> >
> > >
> > > +static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
> > > +{
> > > + dsi->irq_data &= ~irq_bit;
> > > +}
> > > +
> >
> > [snip...]
> >
> > > +
> > > +static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
> > > + unsigned int timeout)
> > > +{
> > > + s32 ret = 0;
> > > + unsigned long jiffies = msecs_to_jiffies(timeout);
> > > +
> > > + ret = wait_event_interruptible_timeout(_dsi_irq_wait_queue,
> > > + dsi->irq_data & irq_flag,
> > > + jiffies);
> > > + if (ret == 0) {
> > > + dev_info(dsi->dev, "Wait DSI IRQ(0x%08x) Timeout\n", irq_flag);
> > > +
> > > + mtk_dsi_enable(dsi);
> > > + mtk_dsi_reset_engine(dsi);
> > > + }
> > > +
> > > + return ret;
> > > +}
> >
> > I think mtk_dsi_irq_data_clear() and mtk_dsi_wait_for_irq_done() should
> > be moved to the 6th patch [1] of this series because these two functions
> > deal the irq control.
> We will move mtk_dsi_irq_data_clear() to patch "drm/mediatek: add dsi
> interrupt control" and put mtk_dsi_wait_for_irq_done() here, because it
> is used in the transfer function.
mtk_dsi_irq_data_clear() is also only used in transfer function now. I
think both function could be used for other application rather than
transfer function, so these two function are general function for irq
control.
Regards,
CK
>
> Regards,
> yt.shen
> >
> >
> > [1] https://patchwork.kernel.org/patch/9310819/
> >
> >
> > Regards,
> > CK
> >
>
>
^ permalink raw reply
* [PATCH v11 5/8] clocksource/drivers/arm_arch_timer: Simplify ACPI support code.
From: Fu Wei @ 2016-09-13 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADyBb7uX79UP=mUxvP-EPGi56-46y2SCMPsWO=Uw-=N0GQERhA@mail.gmail.com>
Hi Thomas, Daniel,
For these arm_arch_timer patches, do you have any other suggestion or comment?
I have deleted "skipping" in the error message.
I have prepared v12 (rebase to rc6 and on the top of IORT v11),
should I send it now (if you are OK with my arm_arch_timer patches ),
or anything I can do to improve this patchset ?
Thanks.
On 7 September 2016 at 17:23, Fu Wei <fu.wei@linaro.org> wrote:
> Hi Thomas
>
> On 6 September 2016 at 22:36, Thomas Gleixner <tglx@linutronix.de> wrote:
>> On Tue, 6 Sep 2016, fu.wei at linaro.org wrote:
>>> + if (timer_count < 0)
>>> + pr_err("Failed to get platform timer info, skipping.\n");
>>
>> So this prints something about skipping. But then it continues as if
>> nothing went wrong. That's either wrong or confusing or both.
>
> yes, you are right, this info is confusing.
> maybe we just delete the "skipping" ?
>
> ?timer_count < 0? is caused by some firmware bug, in gtdt.c:
> ----
> int __init acpi_gtdt_init(struct acpi_table_header *table)
> {
> ......
> if (start < (void *)table + sizeof(struct acpi_table_gtdt)) {
> pr_err(FW_BUG "Failed to retrieve timer info from firmware:
> invalid data.\n");
> return -EINVAL;
> ......
> }
> ----
>
> But in this situation( without platform timers ), system still can work.
> So I thing we just need to print a error.
>
>>
>>> - arch_timer_init();
>>> - return 0;
>>> + return arch_timer_init();
>>
>> Thanks,
>>
>> tglx
>
>
>
> --
> Best regards,
>
> Fu Wei
> Software Engineer
> Red Hat
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ 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