* [PATCH] powerpc/powernv: Fix OPAL LPC access in Little Endian
From: Benjamin Herrenschmidt @ 2013-12-13 4:56 UTC (permalink / raw)
To: linuxppc-dev
We are passing pointers to the firmware for reads, we need to properly
convert the result as OPAL is always BE.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
diff --git a/arch/powerpc/platforms/powernv/opal-lpc.c b/arch/powerpc/platforms/powernv/opal-lpc.c
index e7e59e4..79d83ca 100644
--- a/arch/powerpc/platforms/powernv/opal-lpc.c
+++ b/arch/powerpc/platforms/powernv/opal-lpc.c
@@ -24,25 +24,25 @@ static int opal_lpc_chip_id = -1;
static u8 opal_lpc_inb(unsigned long port)
{
int64_t rc;
- uint32_t data;
+ __be32 data;
if (opal_lpc_chip_id < 0 || port > 0xffff)
return 0xff;
rc = opal_lpc_read(opal_lpc_chip_id, OPAL_LPC_IO, port, &data, 1);
- return rc ? 0xff : data;
+ return rc ? 0xff : be32_to_cpu(data);
}
static __le16 __opal_lpc_inw(unsigned long port)
{
int64_t rc;
- uint32_t data;
+ __be32 data;
if (opal_lpc_chip_id < 0 || port > 0xfffe)
return 0xffff;
if (port & 1)
return (__le16)opal_lpc_inb(port) << 8 | opal_lpc_inb(port + 1);
rc = opal_lpc_read(opal_lpc_chip_id, OPAL_LPC_IO, port, &data, 2);
- return rc ? 0xffff : data;
+ return rc ? 0xffff : be32_to_cpu(data);
}
static u16 opal_lpc_inw(unsigned long port)
{
@@ -52,7 +52,7 @@ static u16 opal_lpc_inw(unsigned long port)
static __le32 __opal_lpc_inl(unsigned long port)
{
int64_t rc;
- uint32_t data;
+ __be32 data;
if (opal_lpc_chip_id < 0 || port > 0xfffc)
return 0xffffffff;
@@ -62,7 +62,7 @@ static __le32 __opal_lpc_inl(unsigned long port)
(__le32)opal_lpc_inb(port + 2) << 8 |
opal_lpc_inb(port + 3);
rc = opal_lpc_read(opal_lpc_chip_id, OPAL_LPC_IO, port, &data, 4);
- return rc ? 0xffffffff : data;
+ return rc ? 0xffffffff : be32_to_cpu(data);
}
static u32 opal_lpc_inl(unsigned long port)
^ permalink raw reply related
* [PATCH] powerpc/powernv: Fix endian issue in opal_xscom_read
From: Anton Blanchard @ 2013-12-13 4:53 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
opal_xscom_read uses a pointer to return the data so we need
to byteswap it on LE builds.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index aded1b8..9873a26 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -811,7 +811,7 @@ int64_t opal_pci_next_error(uint64_t phb_id, uint64_t *first_frozen_pe,
int64_t opal_pci_poll(uint64_t phb_id);
int64_t opal_return_cpu(void);
-int64_t opal_xscom_read(uint32_t gcid, uint32_t pcb_addr, uint64_t *val);
+int64_t opal_xscom_read(uint32_t gcid, uint32_t pcb_addr, __be64 *val);
int64_t opal_xscom_write(uint32_t gcid, uint32_t pcb_addr, uint64_t val);
int64_t opal_lpc_write(uint32_t chip_id, enum OpalLPCAddressType addr_type,
diff --git a/arch/powerpc/platforms/powernv/opal-xscom.c b/arch/powerpc/platforms/powernv/opal-xscom.c
index 4d99a8f..4fbf276 100644
--- a/arch/powerpc/platforms/powernv/opal-xscom.c
+++ b/arch/powerpc/platforms/powernv/opal-xscom.c
@@ -96,9 +96,11 @@ static int opal_scom_read(scom_map_t map, u64 reg, u64 *value)
{
struct opal_scom_map *m = map;
int64_t rc;
+ __be64 v;
reg = opal_scom_unmangle(reg);
- rc = opal_xscom_read(m->chip, m->addr + reg, (uint64_t *)__pa(value));
+ rc = opal_xscom_read(m->chip, m->addr + reg, (__be64 *)__pa(&v));
+ *value = be64_to_cpu(v);
return opal_xscom_err_xlate(rc);
}
^ permalink raw reply related
* Re: [PATCH 1/2] power7, perf: Make some new raw event codes available in sysfs
From: Anshuman Khandual @ 2013-12-13 4:30 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, mikey, sukadev
In-Reply-To: <1386903031.3853.2.camel@concordia>
On 12/13/2013 08:20 AM, Michael Ellerman wrote:
> On Wed, 2013-10-16 at 11:22 +0530, Anshuman Khandual wrote:
>> This patch adds some more raw event codes into the existing list
>> of event codes present in power7-events-list.h file. This tries
>> to complete the list of events supported in Power7 and matches
>> the raw event list with libpfm4 library.
>
> It's a bit annoying, but you also need to update the "ABI" document:
What is annoying ? you need to be specific.
>
> Documentation/ABI/testing/sysfs-bus-event_source-devices-events
>
The events listed under the following heading are events required to do
CPI analysis.
"Description: POWER-systems specific performance monitoring event"
/sys/devices/cpu/events/PM_1PLUS_PPC_CMPL
/sys/devices/cpu/events/PM_BRU_FIN
/sys/devices/cpu/events/PM_BR_MPRED
/sys/devices/cpu/events/PM_CMPLU_STALL
/sys/devices/cpu/events/PM_CMPLU_STALL_BRU
/sys/devices/cpu/events/PM_CMPLU_STALL_DCACHE_MISS
/sys/devices/cpu/events/PM_CMPLU_STALL_DFU
/sys/devices/cpu/events/PM_CMPLU_STALL_DIV
/sys/devices/cpu/events/PM_CMPLU_STALL_ERAT_MISS
/sys/devices/cpu/events/PM_CMPLU_STALL_FXU
/sys/devices/cpu/events/PM_CMPLU_STALL_IFU
/sys/devices/cpu/events/PM_CMPLU_STALL_LSU
/sys/devices/cpu/events/PM_CMPLU_STALL_REJECT
/sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR
/sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR_LONG
/sys/devices/cpu/events/PM_CMPLU_STALL_STORE
/sys/devices/cpu/events/PM_CMPLU_STALL_THRD
/sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR
/sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR_LONG
/sys/devices/cpu/events/PM_CYC
/sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED
/sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED_IC_MISS
/sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
/sys/devices/cpu/events/PM_GCT_NOSLOT_IC_MISS
/sys/devices/cpu/events/PM_GRP_CMPL
/sys/devices/cpu/events/PM_INST_CMPL
/sys/devices/cpu/events/PM_LD_MISS_L1
/sys/devices/cpu/events/PM_LD_REF_L1
/sys/devices/cpu/events/PM_RUN_CYC
/sys/devices/cpu/events/PM_RUN_INST_CMPL
But I am not sure the events the current patch in context adds
+EVENT(PM_1THRD_CON_RUN_INSTR, 0x30062)
+EVENT(PM_CMPLU_STALL_COUNT, 0x4000B)
+EVENT(PM_MEM0_PB_RD_CL, 0x30083)
+EVENT(PM_THRD_1_RUN_CYC, 0x10060)
+EVENT(PM_THRD_2_CONC_RUN_INSTR, 0x40062)
+EVENT(PM_THRD_2_RUN_CYC, 0x20060)
+EVENT(PM_THRD_3_CONC_RUN_INST, 0x10062)
+EVENT(PM_THRD_3_RUN_CYC, 0x30060)
+EVENT(PM_THRD_4_CONC_RUN_INST, 0x20062)
+EVENT(PM_THRD_4_RUN_CYC, 0x40060)
will be helpful in CPI stack analysis and should be part of the ABI
documentation file. If it does, I will be glad to add them.
^ permalink raw reply
* [RFC PATCH] time: Support in tick broadcast framework for archs without an external wakeup source
From: Preeti U Murthy @ 2013-12-13 4:19 UTC (permalink / raw)
To: peterz, fweisbec, paul.gortmaker, paulus, mingo, shangw,
rafael.j.wysocki, galak, benh, paulmck, arnd, linux-pm, rostedt,
michael, john.stultz, tglx, chenhui.zhao, deepthi, r58472, geoff,
linux-kernel, srivatsa.bhat, schwidefsky, svaidy, linuxppc-dev
On some architectures, in certain CPU deep idle states the local timers stop.
An external clock device is used to wakeup these CPUs. The kernel support for the
wakeup of these CPUs is provided by the tick broadcast framework by using the
external clock device as the wakeup source.
However on architectures like PowerPC there is no external clock device. This
patch includes support in the broadcast framework to handle the wakeup of the
CPUs in deep idle states on such architectures by queuing a hrtimer on one of
the CPUs, meant to handle the wakeup of CPUs in deep idle states. This CPU is
identified as the bc_cpu.
Each time the hrtimer expires, it is reprogrammed for the next wakeup of the
CPUs in deep idle state after handling broadcast. However when a CPU is about
to enter deep idle state with its wakeup time earlier than the time at which
the hrtimer is currently programmed, it *becomes the new bc_cpu* and restarts
the hrtimer on itself. This way the job of doing broadcast is handed around to
the CPUs that ask for the earliest wakeup just before entering deep idle
state. This is consistent with what happens in cases where an external clock
device is present. The smp affinity of this clock device is set to the CPU
with the earliest wakeup.
The important point here is that the bc_cpu cannot enter deep idle state
since it has a hrtimer queued to wakeup the other CPUs in deep idle. Hence it
cannot have its local timer stopped. Therefore for such a CPU, the
BROADCAST_ENTER notification has to fail implying that it cannot enter deep
idle state. On architectures where an external clock device is present, all
CPUs can enter deep idle.
During hotplug of the bc_cpu, the job of doing a broadcast is assigned to the
first cpu in the broadcast mask. This newly nominated bc_cpu is woken up by
an IPI so as to queue the above mentioned hrtimer on itself.
This patch is compile tested only.
Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
---
include/linux/clockchips.h | 4 +
kernel/time/clockevents.c | 8 +-
kernel/time/tick-broadcast.c | 157 ++++++++++++++++++++++++++++++++++++++----
kernel/time/tick-internal.h | 8 +-
4 files changed, 153 insertions(+), 24 deletions(-)
diff --git a/include/linux/clockchips.h b/include/linux/clockchips.h
index 493aa02..bbda37b 100644
--- a/include/linux/clockchips.h
+++ b/include/linux/clockchips.h
@@ -186,9 +186,9 @@ static inline int tick_check_broadcast_expired(void) { return 0; }
#endif
#ifdef CONFIG_GENERIC_CLOCKEVENTS
-extern void clockevents_notify(unsigned long reason, void *arg);
+extern int clockevents_notify(unsigned long reason, void *arg);
#else
-static inline void clockevents_notify(unsigned long reason, void *arg) {}
+static inline int clockevents_notify(unsigned long reason, void *arg) {}
#endif
#else /* CONFIG_GENERIC_CLOCKEVENTS_BUILD */
diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 086ad60..bbbd671 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -525,11 +525,11 @@ void clockevents_resume(void)
/**
* clockevents_notify - notification about relevant events
*/
-void clockevents_notify(unsigned long reason, void *arg)
+int clockevents_notify(unsigned long reason, void *arg)
{
struct clock_event_device *dev, *tmp;
unsigned long flags;
- int cpu;
+ int cpu, ret = 0;
raw_spin_lock_irqsave(&clockevents_lock, flags);
@@ -542,11 +542,12 @@ void clockevents_notify(unsigned long reason, void *arg)
case CLOCK_EVT_NOTIFY_BROADCAST_ENTER:
case CLOCK_EVT_NOTIFY_BROADCAST_EXIT:
- tick_broadcast_oneshot_control(reason);
+ ret = tick_broadcast_oneshot_control(reason);
break;
case CLOCK_EVT_NOTIFY_CPU_DYING:
tick_handover_do_timer(arg);
+ tick_handover_bc_cpu(arg);
break;
case CLOCK_EVT_NOTIFY_SUSPEND:
@@ -585,6 +586,7 @@ void clockevents_notify(unsigned long reason, void *arg)
break;
}
raw_spin_unlock_irqrestore(&clockevents_lock, flags);
+ return ret;
}
EXPORT_SYMBOL_GPL(clockevents_notify);
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 9532690..f90b865 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -20,6 +20,7 @@
#include <linux/sched.h>
#include <linux/smp.h>
#include <linux/module.h>
+#include <linux/slab.h>
#include "tick-internal.h"
@@ -35,6 +36,10 @@ static cpumask_var_t tmpmask;
static DEFINE_RAW_SPINLOCK(tick_broadcast_lock);
static int tick_broadcast_force;
+static struct hrtimer *bc_hrtimer;
+static int bc_cpu = -1;
+static ktime_t bc_next_wakeup;
+
#ifdef CONFIG_TICK_ONESHOT
static void tick_broadcast_clear_oneshot(int cpu);
#else
@@ -528,6 +533,20 @@ static int tick_broadcast_set_event(struct clock_event_device *bc, int cpu,
return ret;
}
+static void tick_broadcast_set_next_wakeup(int cpu, ktime_t expires, int force)
+{
+ struct clock_event_device *bc;
+
+ bc = tick_broadcast_device.evtdev;
+
+ if (bc) {
+ tick_broadcast_set_event(bc, cpu, expires, force);
+ } else {
+ hrtimer_start(bc_hrtimer, expires, HRTIMER_MODE_ABS_PINNED);
+ bc_cpu = cpu;
+ }
+}
+
int tick_resume_broadcast_oneshot(struct clock_event_device *bc)
{
clockevents_set_mode(bc, CLOCK_EVT_MODE_ONESHOT);
@@ -558,15 +577,13 @@ void tick_check_oneshot_broadcast(int cpu)
/*
* Handle oneshot mode broadcasting
*/
-static void tick_handle_oneshot_broadcast(struct clock_event_device *dev)
+static int tick_oneshot_broadcast(void)
{
struct tick_device *td;
ktime_t now, next_event;
int cpu, next_cpu = 0;
- raw_spin_lock(&tick_broadcast_lock);
-again:
- dev->next_event.tv64 = KTIME_MAX;
+ bc_next_wakeup.tv64 = KTIME_MAX;
next_event.tv64 = KTIME_MAX;
cpumask_clear(tmpmask);
now = ktime_get();
@@ -620,27 +637,83 @@ again:
* in the event mask
*/
if (next_event.tv64 != KTIME_MAX) {
- /*
- * Rearm the broadcast device. If event expired,
- * repeat the above
- */
- if (tick_broadcast_set_event(dev, next_cpu, next_event, 0))
+ bc_next_wakeup = next_event;
+ }
+
+ return next_cpu;
+}
+
+/*
+ * Handler in oneshot mode for the external clock device
+ */
+static void tick_handle_oneshot_broadcast(struct clock_event_device *dev)
+{
+ int next_cpu;
+
+ raw_spin_lock(&tick_broadcast_lock);
+
+again: next_cpu = tick_oneshot_broadcast();
+ /*
+ * Rearm the broadcast device. If event expired,
+ * repeat the above
+ */
+ if (bc_next_wakeup.tv64 != KTIME_MAX)
+ if (tick_broadcast_set_event(dev, next_cpu, bc_next_wakeup, 0))
goto again;
+
+ raw_spin_unlock(&tick_broadcast_lock);
+}
+
+/*
+ * Handler in oneshot mode for the hrtimer queued when there is no external
+ * clock device.
+ */
+static enum hrtimer_restart handle_broadcast(struct hrtimer *hrtmr)
+{
+ ktime_t now, interval;
+ int next_cpu;
+
+ raw_spin_lock(&tick_broadcast_lock);
+ tick_oneshot_broadcast();
+
+ now = ktime_get();
+
+ if (bc_next_wakeup.tv64 != KTIME_MAX) {
+ interval = ktime_sub(bc_next_wakeup, now);
+ hrtimer_forward_now(bc_hrtimer, interval);
+ raw_spin_unlock(&tick_broadcast_lock);
+ return HRTIMER_RESTART;
}
raw_spin_unlock(&tick_broadcast_lock);
+ return HRTIMER_NORESTART;
+}
+
+/* The CPU could be asked to take over from the previous bc_cpu,
+ * if it is being hotplugged out.
+ */
+static void tick_broadcast_exit_check(int cpu)
+{
+ if (cpu == bc_cpu)
+ hrtimer_start(bc_hrtimer, bc_next_wakeup,
+ HRTIMER_MODE_ABS_PINNED);
+}
+
+static int can_enter_broadcast(int cpu)
+{
+ return cpu != bc_cpu;
}
/*
* Powerstate information: The system enters/leaves a state, where
* affected devices might stop
*/
-void tick_broadcast_oneshot_control(unsigned long reason)
+int tick_broadcast_oneshot_control(unsigned long reason)
{
- struct clock_event_device *bc, *dev;
+ struct clock_event_device *dev;
struct tick_device *td;
unsigned long flags;
ktime_t now;
- int cpu;
+ int cpu, ret = 0;
/*
* Periodic mode does not care about the enter/exit of power
@@ -660,7 +733,6 @@ void tick_broadcast_oneshot_control(unsigned long reason)
if (!(dev->features & CLOCK_EVT_FEAT_C3STOP))
return;
- bc = tick_broadcast_device.evtdev;
raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
if (reason == CLOCK_EVT_NOTIFY_BROADCAST_ENTER) {
@@ -676,12 +748,21 @@ void tick_broadcast_oneshot_control(unsigned long reason)
* woken by the IPI right away.
*/
if (!cpumask_test_cpu(cpu, tick_broadcast_force_mask) &&
- dev->next_event.tv64 < bc->next_event.tv64)
- tick_broadcast_set_event(bc, cpu, dev->next_event, 1);
+ dev->next_event.tv64 < bc_next_wakeup.tv64)
+ bc_next_wakeup = dev->next_event;
+ tick_broadcast_set_next_wakeup(cpu, dev->next_event, 1);
+
+ if (!can_enter_broadcast(cpu)) {
+ cpumask_test_and_clear_cpu(cpu, tick_broadcast_oneshot_mask);
+ clockevents_set_mode(dev, CLOCK_EVT_MODE_ONESHOT);
+ ret = 1;
+ }
}
} else {
if (cpumask_test_and_clear_cpu(cpu, tick_broadcast_oneshot_mask)) {
clockevents_set_mode(dev, CLOCK_EVT_MODE_ONESHOT);
+
+ tick_broadcast_exit_check(cpu);
/*
* The cpu which was handling the broadcast
* timer marked this cpu in the broadcast
@@ -746,6 +827,7 @@ void tick_broadcast_oneshot_control(unsigned long reason)
}
out:
raw_spin_unlock_irqrestore(&tick_broadcast_lock, flags);
+ return ret;
}
/*
@@ -824,15 +906,58 @@ void tick_broadcast_switch_to_oneshot(void)
raw_spin_lock_irqsave(&tick_broadcast_lock, flags);
+ bc_next_wakeup.tv64 = KTIME_MAX;
+
tick_broadcast_device.mode = TICKDEV_MODE_ONESHOT;
bc = tick_broadcast_device.evtdev;
- if (bc)
+ if (bc) {
tick_broadcast_setup_oneshot(bc);
+ bc_next_wakeup = bc->next_event;
+ } else {
+ /* An alternative to tick_broadcast_device on archs which do not have
+ * an external device
+ */
+ bc_hrtimer = kmalloc(sizeof(*bc_hrtimer), GFP_NOWAIT);
+ hrtimer_init(bc_hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS_PINNED);
+ bc_hrtimer->function = handle_broadcast;
+
+ /*
+ * There may be CPUs waiting for periodic broadcast. We need
+ * to set the oneshot bits for those and program the hrtimer
+ * to fire at the next tick period.
+ */
+ cpumask_copy(tmpmask, tick_broadcast_mask);
+ cpumask_clear_cpu(cpu, tmpmask);
+ cpumask_or(tick_broadcast_oneshot_mask,
+ tick_broadcast_oneshot_mask, tmpmask);
+
+ if (!cpumask_empty(tmpmask)) {
+ tick_broadcast_init_next_event(tmpmask,
+ tick_next_period);
+ hrtimer_start(bc_hrtimer, tick_next_period, HRTIMER_MODE_ABS_PINNED);
+ bc_next_wakeup = tick_next_period;
+ }
+ }
raw_spin_unlock_irqrestore(&tick_broadcast_lock, flags);
}
+void tick_handover_bc_cpu(int *cpup)
+{
+ struct tick_device *td;
+
+ if (*cpup == bc_cpu) {
+ int cpu = cpumask_first(tick_broadcast_oneshot_mask);
+
+ bc_cpu = (cpu < nr_cpu_ids) ? cpu : -1;
+ if (bc_cpu != -1) {
+ td = &per_cpu(tick_cpu_device, bc_cpu);
+ td->evtdev->broadcast(cpumask_of(bc_cpu));
+ }
+ }
+}
+
/*
* Remove a dead CPU from broadcasting
*/
diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h
index 18e71f7..1f73032 100644
--- a/kernel/time/tick-internal.h
+++ b/kernel/time/tick-internal.h
@@ -46,23 +46,25 @@ extern int tick_switch_to_oneshot(void (*handler)(struct clock_event_device *));
extern void tick_resume_oneshot(void);
# ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
extern void tick_broadcast_setup_oneshot(struct clock_event_device *bc);
-extern void tick_broadcast_oneshot_control(unsigned long reason);
+extern int tick_broadcast_oneshot_control(unsigned long reason);
extern void tick_broadcast_switch_to_oneshot(void);
extern void tick_shutdown_broadcast_oneshot(unsigned int *cpup);
extern int tick_resume_broadcast_oneshot(struct clock_event_device *bc);
extern int tick_broadcast_oneshot_active(void);
extern void tick_check_oneshot_broadcast(int cpu);
+extern void tick_handover_bc_cpu(int *cpup);
bool tick_broadcast_oneshot_available(void);
# else /* BROADCAST */
static inline void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
{
BUG();
}
-static inline void tick_broadcast_oneshot_control(unsigned long reason) { }
+static inline int tick_broadcast_oneshot_control(unsigned long reason) { }
static inline void tick_broadcast_switch_to_oneshot(void) { }
static inline void tick_shutdown_broadcast_oneshot(unsigned int *cpup) { }
static inline int tick_broadcast_oneshot_active(void) { return 0; }
static inline void tick_check_oneshot_broadcast(int cpu) { }
+static inline void tick_handover_bc_cpu(int *cpup) {}
static inline bool tick_broadcast_oneshot_available(void) { return true; }
# endif /* !BROADCAST */
@@ -87,7 +89,7 @@ static inline void tick_broadcast_setup_oneshot(struct clock_event_device *bc)
{
BUG();
}
-static inline void tick_broadcast_oneshot_control(unsigned long reason) { }
+static inline int tick_broadcast_oneshot_control(unsigned long reason) { }
static inline void tick_shutdown_broadcast_oneshot(unsigned int *cpup) { }
static inline int tick_resume_broadcast_oneshot(struct clock_event_device *bc)
{
^ permalink raw reply related
* RE: [PATCH v7] clk: corenet: Adds the clock binding
From: Yuantian Tang @ 2013-12-13 3:39 UTC (permalink / raw)
To: Scott Wood; +Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1384938289-24713-1-git-send-email-Yuantian.Tang@freescale.com>
UElORy4NCg0KVGhhbmtzLA0KWXVhbnRpYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPiBGcm9tOiBUYW5nIFl1YW50aWFuLUIyOTk4Mw0KPiBTZW50OiAyMDEzxOoxMdTCMjDI1SDQ
x8bayP0gMTc6MDUNCj4gVG86IGdhbGFrQGtlcm5lbC5jcmFzaGluZy5vcmcNCj4gQ2M6IGRldmlj
ZXRyZWVAdmdlci5rZXJuZWwub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsNCj4g
bWFyay5ydXRsYW5kQGFybS5jb207IFdvb2QgU2NvdHQtQjA3NDIxOyBncmFudC5saWtlbHlAc2Vj
cmV0bGFiLmNhOyBUYW5nDQo+IFl1YW50aWFuLUIyOTk4MzsgVGFuZyBZdWFudGlhbi1CMjk5ODM7
IExpIFlhbmctTGVvLVI1ODQ3Mg0KPiBTdWJqZWN0OiBbUEFUQ0ggdjddIGNsazogY29yZW5ldDog
QWRkcyB0aGUgY2xvY2sgYmluZGluZw0KPiANCj4gRnJvbTogVGFuZyBZdWFudGlhbiA8eXVhbnRp
YW4udGFuZ0BmcmVlc2NhbGUuY29tPg0KPiANCj4gQWRkcyB0aGUgY2xvY2sgYmluZGluZ3MgZm9y
IEZyZWVzY2FsZSBQb3dlclBDIENvcmVOZXQgcGxhdGZvcm1zDQo+IA0KPiBTaWduZWQtb2ZmLWJ5
OiBUYW5nIFl1YW50aWFuIDxZdWFudGlhbi5UYW5nQGZyZWVzY2FsZS5jb20+DQo+IFNpZ25lZC1v
ZmYtYnk6IExpIFlhbmcgPGxlb2xpQGZyZWVzY2FsZS5jb20+DQo+IC0tLQ0KPiB2NzoNCj4gCS0g
cmVmaW5lZCBzb21lIHByb3BlcnRpZXMnIGRlZmluaXRpb25zDQo+IHY2Og0KPiAJLSBzcGxpdGVk
IHRoZSBwcmV2aW91cyBwYXRjaCBpbnRvIDIgcGFydHMsIG9uZSBpcyBmb3IgYmluZGluZyh0aGlz
DQo+IG9uZSksDQo+IAkgIHRoZSBvdGhlciBpcyBmb3IgRFRTIG1vZGlmaWNhdGlvbih3aWxsIHN1
Ym1pdCBvbmNlIHRoaXMgZ2V0cw0KPiBhY2NlcHRlZCkNCj4gCS0gZml4ZWQgdHlwbw0KPiAJLSBy
ZWZpbmVkICNjbG9jay1jZWxscyBhbmQgY2xvY2stb3V0cHV0LW5hbWVzIHByb3BlcnRpZXMNCj4g
CS0gcmVtb3ZlZCBmaXhlZC1jbG9jayBjb21wYXRpYmxlIHN0cmluZw0KPiB2NToNCj4gCS0gcmVm
aW5lIHRoZSBiaW5kaW5nIGRvY3VtZW50DQo+IAktIHVwZGF0ZSB0aGUgY29tcGF0aWJsZSBzdHJp
bmcNCj4gdjQ6DQo+IAktIGFkZCBiaW5kaW5nIGRvY3VtZW50DQo+IAktIHVwZGF0ZSBjb21wYXRp
YmxlIHN0cmluZw0KPiAJLSB1cGRhdGUgdGhlIHJlZyBwcm9wZXJ0eQ0KPiB2MzoNCj4gCS0gZml4
IHR5cG8NCj4gdjI6DQo+IAktIGFkZCB0NDI0MCwgYjQ0MjAsIGI0ODYwIHN1cHBvcnQNCj4gCS0g
cmVtb3ZlIHBsbC80IGNsb2NrIGZyb20gcDIwNDEsIHAzMDQxIGFuZCBwNTAyMCBib2FyZA0KPiAg
Li4uL2RldmljZXRyZWUvYmluZGluZ3MvY2xvY2svY29yZW5ldC1jbG9jay50eHQgICAgfCAxMjgN
Cj4gKysrKysrKysrKysrKysrKysrKysrDQo+ICAxIGZpbGUgY2hhbmdlZCwgMTI4IGluc2VydGlv
bnMoKykNCj4gIGNyZWF0ZSBtb2RlIDEwMDY0NCBEb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmlu
ZGluZ3MvY2xvY2svY29yZW5ldC0NCj4gY2xvY2sudHh0DQo+IA0KPiBkaWZmIC0tZ2l0IGEvRG9j
dW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Nsb2NrL2NvcmVuZXQtY2xvY2sudHh0DQo+
IGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Nsb2NrL2NvcmVuZXQtY2xvY2su
dHh0DQo+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0DQo+IGluZGV4IDAwMDAwMDAuLjYwOWJhMmINCj4g
LS0tIC9kZXYvbnVsbA0KPiArKysgYi9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3Mv
Y2xvY2svY29yZW5ldC1jbG9jay50eHQNCj4gQEAgLTAsMCArMSwxMjggQEANCj4gKyogQ2xvY2sg
QmxvY2sgb24gRnJlZXNjYWxlIENvcmVOZXQgUGxhdGZvcm1zDQo+ICsNCj4gK0ZyZWVzY2FsZSBD
b3JlTmV0IGNoaXBzIHRha2UgcHJpbWFyeSBjbG9ja2luZyBpbnB1dCBmcm9tIHRoZSBleHRlcm5h
bA0KPiArU1lTQ0xLIHNpZ25hbC4gVGhlIFNZU0NMSyBpbnB1dCAoZnJlcXVlbmN5KSBpcyBtdWx0
aXBsaWVkIHVzaW5nDQo+ICttdWx0aXBsZSBwaGFzZSBsb2NrZWQgbG9vcHMgKFBMTCkgdG8gY3Jl
YXRlIGEgdmFyaWV0eSBvZiBmcmVxdWVuY2llcw0KPiArd2hpY2ggY2FuIHRoZW4gYmUgcGFzc2Vk
IHRvIGEgdmFyaWV0eSBvZiBpbnRlcm5hbCBsb2dpYywgaW5jbHVkaW5nDQo+ICtjb3JlcyBhbmQg
cGVyaXBoZXJhbCBJUCBibG9ja3MuDQo+ICtQbGVhc2UgcmVmZXIgdG8gdGhlIFJlZmVyZW5jZSBN
YW51YWwgZm9yIGRldGFpbHMuDQo+ICsNCj4gKzEuIENsb2NrIEJsb2NrIEJpbmRpbmcNCj4gKw0K
PiArUmVxdWlyZWQgcHJvcGVydGllczoNCj4gKy0gY29tcGF0aWJsZTogU2hvdWxkIGNvbnRhaW4g
YSBzcGVjaWZpYyBjbG9jayBibG9jayBjb21wYXRpYmxlIHN0cmluZw0KPiArCWFuZCBhIHNpbmds
ZSBjaGFzc2lzIGNsb2NrIGNvbXBhdGlibGUgc3RyaW5nLg0KPiArCUNsb2NrIGJsb2NrIHN0cmlu
Z3MgaW5jbHVkZSwgYnV0IG5vdCBsaW1pdGVkIHRvLCBvbmUgb2YgdGhlOg0KPiArCSogImZzbCxw
MjA0MS1jbG9ja2dlbiINCj4gKwkqICJmc2wscDMwNDEtY2xvY2tnZW4iDQo+ICsJKiAiZnNsLHA0
MDgwLWNsb2NrZ2VuIg0KPiArCSogImZzbCxwNTAyMC1jbG9ja2dlbiINCj4gKwkqICJmc2wscDUw
NDAtY2xvY2tnZW4iDQo+ICsJKiAiZnNsLHQ0MjQwLWNsb2NrZ2VuIg0KPiArCSogImZzbCxiNDQy
MC1jbG9ja2dlbiINCj4gKwkqICJmc2wsYjQ4NjAtY2xvY2tnZW4iDQo+ICsJQ2hhc3NpcyBjbG9j
ayBzdHJpbmdzIGluY2x1ZGU6DQo+ICsJKiAiZnNsLHFvcmlxLWNsb2NrZ2VuLTEuMCI6IGZvciBj
aGFzc2lzIDEuMCBjbG9ja3MNCj4gKwkqICJmc2wscW9yaXEtY2xvY2tnZW4tMi4wIjogZm9yIGNo
YXNzaXMgMi4wIGNsb2Nrcw0KPiArLSByZWc6IE9mZnNldCBhbmQgbGVuZ3RoIG9mIHRoZSBjbG9j
ayByZWdpc3RlciBzZXQNCj4gKw0KPiArUmVjb21tZW5kZWQgcHJvcGVydGllczoNCj4gKy0gcmFu
Z2VzOiBBbGxvd3MgdmFsaWQgdHJhbnNsYXRpb24gYmV0d2VlbiBjaGlsZCdzIGFkZHJlc3Mgc3Bh
Y2UgYW5kDQo+ICsJcGFyZW50J3MuIE11c3QgYmUgcHJlc2VudCBpZiB0aGUgZGV2aWNlIGhhcyBz
dWItbm9kZXMuDQo+ICstICNhZGRyZXNzLWNlbGxzOiBTcGVjaWZpZXMgdGhlIG51bWJlciBvZiBj
ZWxscyB1c2VkIHRvIHJlcHJlc2VudA0KPiArCXBoeXNpY2FsIGJhc2UgYWRkcmVzc2VzLiAgTXVz
dCBiZSBwcmVzZW50IGlmIHRoZSBkZXZpY2UgaGFzDQo+ICsJc3ViLW5vZGVzIGFuZCBzZXQgdG8g
MSBpZiBwcmVzZW50DQo+ICstICNzaXplLWNlbGxzOiBTcGVjaWZpZXMgdGhlIG51bWJlciBvZiBj
ZWxscyB1c2VkIHRvIHJlcHJlc2VudA0KPiArCXRoZSBzaXplIG9mIGFuIGFkZHJlc3MuIE11c3Qg
YmUgcHJlc2VudCBpZiB0aGUgZGV2aWNlIGhhcw0KPiArCXN1Yi1ub2RlcyBhbmQgc2V0IHRvIDEg
aWYgcHJlc2VudA0KPiArDQo+ICsyLiBDbG9jayBQcm92aWRlci9Db25zdW1lciBCaW5kaW5nDQo+
ICsNCj4gK01vc3Qgb2YgdGhlIGJpbmRpbmdzIGFyZSBmcm9tIHRoZSBjb21tb24gY2xvY2sgYmlu
ZGluZ1sxXS4NCj4gKyBbMV0gRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Nsb2Nr
L2Nsb2NrLWJpbmRpbmdzLnR4dA0KPiArDQo+ICtSZXF1aXJlZCBwcm9wZXJ0aWVzOg0KPiArLSBj
b21wYXRpYmxlIDogU2hvdWxkIGluY2x1ZGUgb25lIG9mIHRoZSBmb2xsb3dpbmc6DQo+ICsJKiAi
ZnNsLHFvcmlxLWNvcmUtcGxsLTEuMCIgZm9yIGNvcmUgUExMIGNsb2NrcyAodjEuMCkNCj4gKyAg
ICAqICJmc2wscW9yaXEtY29yZS1wbGwtMi4wIiBmb3IgY29yZSBQTEwgY2xvY2tzICh2Mi4wKQ0K
PiArICAgICogImZzbCxxb3JpcS1jb3JlLW11eC0xLjAiIGZvciBjb3JlIG11eCBjbG9ja3MgKHYx
LjApDQo+ICsgICAgKiAiZnNsLHFvcmlxLWNvcmUtbXV4LTIuMCIgZm9yIGNvcmUgbXV4IGNsb2Nr
cyAodjIuMCkNCj4gKwkqICJmc2wscW9yaXEtc3lzY2xrLTEuMCI6IGZvciBpbnB1dCBzeXN0ZW0g
Y2xvY2sgKHYxLjApDQo+ICsJKiAiZnNsLHFvcmlxLXN5c2Nsay0yLjAiOiBmb3IgaW5wdXQgc3lz
dGVtIGNsb2NrICh2Mi4wKQ0KPiArLSAjY2xvY2stY2VsbHM6IEZyb20gY29tbW9uIGNsb2NrIGJp
bmRpbmcuIFRoZSBudW1iZXIgb2YgY2VsbHMgaW4gYQ0KPiArCWNsb2NrLXNwZWNpZmllci4gU2hv
dWxkIGJlIDwwPiBmb3IgImZzbCxxb3JpcS1zeXNjbGstWzEsMl0uMCINCj4gKwljbG9ja3MsIG9y
IDwxPiBmb3IgImZzbCxxb3JpcS1jb3JlLXBsbC1bMSwyXS4wIiBjbG9ja3MuDQo+ICsJRm9yICJm
c2wscW9yaXEtY29yZS1wbGwtWzEsMl0uMCIgY2xvY2tzLCB0aGUgc2luZ2xlDQo+ICsJY2xvY2st
c3BlY2lmaWVyIGNlbGwgbWF5IHRha2UgdGhlIGZvbGxvd2luZyB2YWx1ZXM6DQo+ICsJKiAwIC0g
ZXF1YWwgdG8gdGhlIFBMTCBmcmVxdWVuY3kNCj4gKwkqIDEgLSBlcXVhbCB0byB0aGUgUExMIGZy
ZXF1ZW5jeSBkaXZpZGVkIGJ5IDINCj4gKwkqIDIgLSBlcXVhbCB0byB0aGUgUExMIGZyZXF1ZW5j
eSBkaXZpZGVkIGJ5IDQNCj4gKw0KPiArUmVjb21tZW5kZWQgcHJvcGVydGllczoNCj4gKy0gY2xv
Y2tzOiBTaG91bGQgYmUgdGhlIHBoYW5kbGUgb2YgaW5wdXQgcGFyZW50IGNsb2NrDQo+ICstIGNs
b2NrLW5hbWVzOiBGcm9tIGNvbW1vbiBjbG9jayBiaW5kaW5nLCBpbmRpY2F0ZXMgdGhlIGNsb2Nr
IG5hbWUNCj4gKy0gY2xvY2stb3V0cHV0LW5hbWVzOiBGcm9tIGNvbW1vbiBjbG9jayBiaW5kaW5n
LCBpbmRpY2F0ZXMgdGhlIG5hbWVzIG9mDQo+ICsJb3V0cHV0IGNsb2Nrcw0KPiArLSByZWc6IFNo
b3VsZCBiZSB0aGUgb2Zmc2V0IGFuZCBsZW5ndGggb2YgY2xvY2sgYmxvY2sgYmFzZSBhZGRyZXNz
Lg0KPiArCVRoZSBsZW5ndGggc2hvdWxkIGJlIDQuDQo+ICsNCj4gK0V4YW1wbGUgZm9yIGNsb2Nr
IGJsb2NrIGFuZCBjbG9jayBwcm92aWRlcjoNCj4gKy8gew0KPiArCWNsb2NrZ2VuOiBnbG9iYWwt
dXRpbGl0aWVzQGUxMDAwIHsNCj4gKwkJY29tcGF0aWJsZSA9ICJmc2wscDUwMjAtY2xvY2tnZW4i
LCAiZnNsLHFvcmlxLWNsb2NrZ2VuLTEuMCI7DQo+ICsJCXJhbmdlcyA9IDwweDAgMHhlMTAwMCAw
eDEwMDA+Ow0KPiArCQlyZWcgPSA8MHhlMTAwMCAweDEwMDA+Ow0KPiArCQkjYWRkcmVzcy1jZWxs
cyA9IDwxPjsNCj4gKwkJI3NpemUtY2VsbHMgPSA8MT47DQo+ICsNCj4gKwkJc3lzY2xrOiBzeXNj
bGsgew0KPiArCQkJI2Nsb2NrLWNlbGxzID0gPDA+Ow0KPiArCQkJY29tcGF0aWJsZSA9ICJmc2ws
cW9yaXEtc3lzY2xrLTEuMCI7DQo+ICsJCQljbG9jay1vdXRwdXQtbmFtZXMgPSAic3lzY2xrIjsN
Cj4gKwkJfQ0KPiArDQo+ICsJCXBsbDA6IHBsbDBAODAwIHsNCj4gKwkJCSNjbG9jay1jZWxscyA9
IDwxPjsNCj4gKwkJCXJlZyA9IDwweDgwMCAweDQ+Ow0KPiArCQkJY29tcGF0aWJsZSA9ICJmc2ws
cW9yaXEtY29yZS1wbGwtMS4wIjsNCj4gKwkJCWNsb2NrcyA9IDwmc3lzY2xrPjsNCj4gKwkJCWNs
b2NrLW91dHB1dC1uYW1lcyA9ICJwbGwwIiwgInBsbDAtZGl2MiI7DQo+ICsJCX07DQo+ICsNCj4g
KwkJcGxsMTogcGxsMUA4MjAgew0KPiArCQkJI2Nsb2NrLWNlbGxzID0gPDE+Ow0KPiArCQkJcmVn
ID0gPDB4ODIwIDB4ND47DQo+ICsJCQljb21wYXRpYmxlID0gImZzbCxxb3JpcS1jb3JlLXBsbC0x
LjAiOw0KPiArCQkJY2xvY2tzID0gPCZzeXNjbGs+Ow0KPiArCQkJY2xvY2stb3V0cHV0LW5hbWVz
ID0gInBsbDEiLCAicGxsMS1kaXYyIjsNCj4gKwkJfTsNCj4gKw0KPiArCQltdXgwOiBtdXgwQDAg
ew0KPiArCQkJI2Nsb2NrLWNlbGxzID0gPDA+Ow0KPiArCQkJcmVnID0gPDB4MCAweDQ+Ow0KPiAr
CQkJY29tcGF0aWJsZSA9ICJmc2wscW9yaXEtY29yZS1tdXgtMS4wIjsNCj4gKwkJCWNsb2NrcyA9
IDwmcGxsMCAwPiwgPCZwbGwwIDE+LCA8JnBsbDEgMD4sIDwmcGxsMSAxPjsNCj4gKwkJCWNsb2Nr
LW5hbWVzID0gInBsbDAiLCAicGxsMC1kaXYyIiwgInBsbDEiLCAicGxsMS1kaXYyIjsNCj4gKwkJ
CWNsb2NrLW91dHB1dC1uYW1lcyA9ICJjbXV4MCI7DQo+ICsJCX07DQo+ICsNCj4gKwkJbXV4MTog
bXV4MUAyMCB7DQo+ICsJCQkjY2xvY2stY2VsbHMgPSA8MD47DQo+ICsJCQlyZWcgPSA8MHgyMCAw
eDQ+Ow0KPiArCQkJY29tcGF0aWJsZSA9ICJmc2wscW9yaXEtY29yZS1tdXgtMS4wIjsNCj4gKwkJ
CWNsb2NrcyA9IDwmcGxsMCAwPiwgPCZwbGwwIDE+LCA8JnBsbDEgMD4sIDwmcGxsMSAxPjsNCj4g
KwkJCWNsb2NrLW5hbWVzID0gInBsbDAiLCAicGxsMC1kaXYyIiwgInBsbDEiLCAicGxsMS1kaXYy
IjsNCj4gKwkJCWNsb2NrLW91dHB1dC1uYW1lcyA9ICJjbXV4MSI7DQo+ICsJCX07DQo+ICsJfTsN
Cj4gKyAgfQ0KPiArDQo+ICtFeGFtcGxlIGZvciBjbG9jayBjb25zdW1lcjoNCj4gKw0KPiArLyB7
DQo+ICsJY3B1MDogUG93ZXJQQyxlNTUwMEAwIHsNCj4gKwkJLi4uDQo+ICsJCWNsb2NrcyA9IDwm
bXV4MD47DQo+ICsJCS4uLg0KPiArCX07DQo+ICsgIH0NCj4gLS0NCj4gMS44LjANCg0K
^ permalink raw reply
* Re: [1/3] powerpc/vfio: Enable on POWERNV platform
From: Alexey Kardashevskiy @ 2013-12-13 3:02 UTC (permalink / raw)
To: Scott Wood
Cc: kvm, linux-kernel, Bharat Bhushan, Alex Williamson,
Paul Mackerras, Varun Sethi, linuxppc-dev, David Gibson
In-Reply-To: <20131212233527.GA16929@home.buserror.net>
On 12/13/2013 10:35 AM, Scott Wood wrote:
> On Tue, May 21, 2013 at 01:33:09PM +1000, Alexey Kardashevskiy wrote:
>> +static int iommu_add_device(struct device *dev)
>> +{
>> + struct iommu_table *tbl;
>> + int ret = 0;
>> +
>> + if (WARN_ON(dev->iommu_group)) {
>> + pr_warn("iommu_tce: device %s is already in iommu group %d, skipping\n",
>> + dev_name(dev),
>> + iommu_group_id(dev->iommu_group));
>> + return -EBUSY;
>> + }
> [snip]
>> +static int __init tce_iommu_init(void)
>> +{
>> + struct pci_dev *pdev = NULL;
>> +
>> + BUILD_BUG_ON(PAGE_SIZE < IOMMU_PAGE_SIZE);
>> +
>> + for_each_pci_dev(pdev)
>> + iommu_add_device(&pdev->dev);
>> +
>> + bus_register_notifier(&pci_bus_type, &tce_iommu_bus_nb);
>> + return 0;
>> +}
>> +
>> +subsys_initcall_sync(tce_iommu_init);
>
> This is missing a check to see whether the appropriate hardware is
> present. This file should also be renamed to something less generic, and
> depend on a kconfig symbol more specific than CONFIG_PPC64.
>
> When this is combined with CONFIG_FSL_PAMU on hardware with a PAMU, I get
> a bunch of those "WARN_ON(dev->iommu_group)" dumps because PAMU already
> got to them. Presumably without PAMU it silently (or with just pr_debug)
> bails out at some other point.
I posted (yet again) yesterday "[PATCH v11] PPC: POWERNV: move
iommu_add_device earlier" which should fix this. And Bharat asked many
times for this to get accepted :)
--
Alexey
^ permalink raw reply
* Re: powerpc/powernv: Framework to log critical errors on powernv.
From: Benjamin Herrenschmidt @ 2013-12-13 2:58 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Deepthi Dharwar, PowerPC email list
In-Reply-To: <1386900030.21216.7.camel@concordia>
On Fri, 2013-12-13 at 13:00 +1100, Michael Ellerman wrote:
> None of the above seem to be used anywhere.
They are the arguments you pass when creating an error log, ie, they
are the values that are used by the firmware to generate the actual
error log entry.
They will be used as we add code that generate error log entries
subsequently.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] power7, perf: Make some new raw event codes available in sysfs
From: Michael Ellerman @ 2013-12-13 2:50 UTC (permalink / raw)
To: Anshuman Khandual; +Cc: linuxppc-dev, mikey, sukadev
In-Reply-To: <1381902780-2719-2-git-send-email-khandual@linux.vnet.ibm.com>
On Wed, 2013-10-16 at 11:22 +0530, Anshuman Khandual wrote:
> This patch adds some more raw event codes into the existing list
> of event codes present in power7-events-list.h file. This tries
> to complete the list of events supported in Power7 and matches
> the raw event list with libpfm4 library.
It's a bit annoying, but you also need to update the "ABI" document:
Documentation/ABI/testing/sysfs-bus-event_source-devices-events
Please do so and resend.
cheers
^ permalink raw reply
* Re: [PATCH V4 08/10] powerpc, perf: Enable SW filtering in branch stack sampling framework
From: Michael Ellerman @ 2013-12-13 2:47 UTC (permalink / raw)
To: Anshuman Khandual
Cc: mikey, ak, linux-kernel, eranian, linuxppc-dev, acme, sukadev,
mingo
In-Reply-To: <52A9779B.1030003@linux.vnet.ibm.com>
On Thu, 2013-12-12 at 14:15 +0530, Anshuman Khandual wrote:
> On 12/10/2013 11:27 AM, Anshuman Khandual wrote:
> > On 12/09/2013 11:51 AM, Michael Ellerman wrote:
> >> This code was already in need of some unindentation, and now it's just
> >> ridiculous.
> >>
> >> To start with at the beginning of this routine we have:
> >>
> >> while (..) {
> >> if (!val)
> >> break;
> >> else {
> >> // Bulk of the logic
> >> ...
> >> }
> >> }
> >>
> >> That should almost always become:
> >>
> >> while (..) {
> >> if (!val)
> >> break;
> >>
> >> // Bulk of the logic
> >> ...
> >> }
> >>
> >>
> >> But in this case that's not enough. Please send a precursor patch which moves
> >> this logic out into a helper function.
> >
> > Hey Michael,
> >
> > I believe this patch should be able to take care of this.
...
> Does the patch looks okay ? In which case will send it out separately. Do let
> me know. Thank you.
It's OK.
Don't send it out separately, make it the first patch in your series.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: set default kernel thread priority to medium-low
From: Michael Ellerman @ 2013-12-13 2:03 UTC (permalink / raw)
To: Philippe Bergheaud; +Cc: Linuxppc-dev
In-Reply-To: <52A961A0.5010307@linux.vnet.ibm.com>
On Thu, 2013-12-12 at 08:11 +0100, Philippe Bergheaud wrote:
> Michael Ellerman wrote:
> > On Wed, 2013-12-11 at 11:30 +0100, Philippe Bergheaud wrote:
> >
> >>Shouldn't we define a new macro HMT_DEFAULT, to identify explicitely where
> >>the default priority is required?
> >
> >
> > That might help clarify things yes.
>
> Thank you for the help. I will rework this.
Thanks.
^ permalink raw reply
* Re: powerpc/powernv: Framework to log critical errors on powernv.
From: Michael Ellerman @ 2013-12-13 2:00 UTC (permalink / raw)
To: Deepthi Dharwar; +Cc: PowerPC email list
In-Reply-To: <52A99D47.4090503@linux.vnet.ibm.com>
On Thu, 2013-12-12 at 16:55 +0530, Deepthi Dharwar wrote:
> powerpc/powernv: Framework to log critical errors on powernv.
>
> From: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
>
> This patch provides error logging interfaces to report critical
> powernv error logs to FSP.
> All the required information to dump the error is collected
> at POWERNV level through error log interfaces
> and then pushed on to FSP.
>
> Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/opal.h | 125 ++++++++++++++++++++++++
> arch/powerpc/platforms/powernv/opal-elog.c | 59 +++++++++++
> arch/powerpc/platforms/powernv/opal-wrappers.S | 1
> 3 files changed, 184 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
> index be404ea..b8d1dd4 100644
> --- a/arch/powerpc/include/asm/opal.h
> +++ b/arch/powerpc/include/asm/opal.h
> @@ -134,6 +134,7 @@ extern int opal_enter_rtas(struct rtas_args *args,
> #define OPAL_ELOG_ACK 73
> #define OPAL_ELOG_RESEND 74
> #define OPAL_ELOG_SIZE 75
> +#define OPAL_ELOG_SEND 87
>
> #ifndef __ASSEMBLY__
>
> @@ -216,6 +217,122 @@ enum OpalPendingState {
> OPAL_EVENT_PCI_ERROR = 0x200
> };
>
> +/* Classification of Error/Events reporting type classification
> + * Platform Events/Errors: Report Machine Check Interrupt
> + * INPUT_OUTPUT: Report all I/O related events/errors
> + * RESOURCE_DEALLOC: Hotplug events and errors
> + * MISC: Miscellanous error
> + * Field: error_events_type
> + */
> +enum Error_Events {
> + OPAL_PLATFORM,
> + OPAL_INPUT_OUTPUT,
> + OPAL_RESOURCE_DEALLOC,
> + OPAL_MISC,
> +};
> +
> +/* OPAL Subsystem IDs listed for reporting events/errors
> + * Field: subsystem_id
> + */
> +
> +#define OPAL_PROCESSOR_SUBSYSTEM 0x10
> +#define OPAL_MEMORY_SUBSYSTEM 0x20
> +#define OPAL_IO_SUBSYSTEM 0x30
> +#define OPAL_IO_DEVICES 0x40
> +#define OPAL_CEC_HARDWARE 0x50
> +#define OPAL_POWER_COOLING 0x60
> +#define OPAL_MISC_SUBSYSTEM 0x70
> +#define OPAL_SURVEILLANCE_ERR 0x7A
> +#define OPAL_PLATFORM_FIRMWARE 0x80
> +#define OPAL_SOFTWARE 0x90
> +#define OPAL_EXTERNAL_ENV 0xA0
> +
> +/* During reporting an event/error the following represents
> + * how serious the logged event/error is. (Severity)
> + * Field: event_sev
> + */
> +#define OPAL_INFO 0x00
> +#define OPAL_RECOVERED_ERR_GENERAL 0x10
> +
> +/* 0x2X series is to denote set of Predictive Error
> + * 0x20 Generic predictive error
> + * 0x21 Predictive error, degraded performance
> + * 0x22 Predictive error, fault may be corrected after reboot
> + * 0x23 Predictive error, fault may be corrected after reboot,
> + * degraded performance
> + * 0x24 Predictive error, loss of redundancy
> + */
> +#define OPAL_PREDICTIVE_ERR_GENERAL 0x20
> +#define OPAL_PREDICTIVE_ERR_DEGRADED_PERF 0x21
> +#define OPAL_PREDICTIVE_ERR_FAULT_RECTIFY_REBOOT 0x22
> +#define OPAL_PREDICTIVE_ERR_FAULT_RECTIFY_BOOT_DEGRADE_PERF 0x23
> +#define OPAL_PREDICTIVE_ERR_LOSS_OF_REDUNDANCY 0x24
> +
> +/* 0x4X series for Unrecoverable Error
> + * 0x40 Generic Unrecoverable error
> + * 0x41 Unrecoverable error bypassed with degraded performance
> + * 0x44 Unrecoverable error bypassed with loss of redundancy
> + * 0x45 Unrecoverable error bypassed with loss of redundancy and performance
> + * 0x48 Unrecoverable error bypassed with loss of function
> + */
> +#define OPAL_UNRECOVERABLE_ERR_GENERAL 0x40
> +#define OPAL_UNRECOVERABLE_ERR_DEGRADE_PERF 0x41
> +#define OPAL_UNRECOVERABLE_ERR_LOSS_REDUNDANCY 0x44
> +#define OPAL_UNRECOVERABLE_ERR_LOSS_REDUNDANCY_PERF 0x45
> +#define OPAL_UNRECOVERABLE_ERR_LOSS_OF_FUNCTION 0x48
> +
> +/* Event Sub-type
> + * This field provides additional information on the non-error
> + * event type
> + * Field: event_subtype
> + */
> +#define OPAL_NA 0x00
> +#define OPAL_MISCELLANEOUS_INFO_ONLY 0x01
> +#define OPAL_PREV_REPORTED_ERR_RECTIFIED 0x10
> +#define OPAL_SYS_RESOURCES_DECONFIG_BY_USER 0x20
> +#define OPAL_SYS_RESOURCE_DECONFIG_PRIOR_ERR 0x21
> +#define OPAL_RESOURCE_DEALLOC_EVENT_NOTIFY 0x22
> +#define OPAL_CONCURRENT_MAINTENANCE_EVENT 0x40
> +#define OPAL_CAPACITY_UPGRADE_EVENT 0x60
> +#define OPAL_RESOURCE_SPARING_EVENT 0x70
> +#define OPAL_DYNAMIC_RECONFIG_EVENT 0x80
> +#define OPAL_NORMAL_SYS_PLATFORM_SHUTDOWN 0xD0
> +#define OPAL_ABNORMAL_POWER_OFF 0xE0
None of the above seem to be used anywhere.
cheers
^ permalink raw reply
* Re: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
From: Sinan Akman @ 2013-12-13 0:29 UTC (permalink / raw)
To: Scott Wood
Cc: Mike Turquette, Detlev Zundel, Gerhard Sittig, Matteo Facchinetti,
Anatolij Gustschin, linuxppc-dev
In-Reply-To: <1386876720.10013.260.camel@snotra.buserror.net>
Scott Wood wrote:
> On Thu, 2013-12-12 at 18:46 +0100, Sinan Akman wrote:
>> Matteo Facchinetti wrote:
>>> [...]
>>> - NFC: one of the biggest unsolved mystery
>>> Is this ip-core used in others microcontrollers? Seems to be used only
>>> in mpc5125!!!
>> I don't think that IP is used in any other FSL SoC. Scott can probably
>> confirm this for us.
>
> That's a different part of Freescale, so I don't know much about it, but
> it looks pretty similar to MXC NAND. Back when those drivers were
> submitted I tried to get the authors of each to work together to see if
> a common driver made sense, but I got little response.
OK Scott thanks for your comments. I am somewhat deep in 5125 NFC. I will
take a look at mxc nand and see how similar they are. Who is maintaining
mxc nand ? I might spend some time and create some common components.
But right now I am not familiar with mxc nand.
Thanks
Sinan Akman
^ permalink raw reply
* AUTO: Michael Barry is out of the office (returning 17/12/2013)
From: Michael Barry @ 2013-12-12 23:58 UTC (permalink / raw)
To: linuxppc-dev
I am out of the office until 17/12/2013.
Note: This is an automated response to your message "Linuxppc-dev Digest,
Vol 112, Issue 55" sent on 12/12/2013 23:35:43.
This is the only notification you will receive while this person is away.
^ permalink raw reply
* Re: [1/3] powerpc/vfio: Enable on POWERNV platform
From: Scott Wood @ 2013-12-12 23:35 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm, linux-kernel, Alex Williamson, Paul Mackerras, Varun Sethi,
linuxppc-dev, David Gibson
In-Reply-To: <1369107191-28547-2-git-send-email-aik@ozlabs.ru>
On Tue, May 21, 2013 at 01:33:09PM +1000, Alexey Kardashevskiy wrote:
> +static int iommu_add_device(struct device *dev)
> +{
> + struct iommu_table *tbl;
> + int ret = 0;
> +
> + if (WARN_ON(dev->iommu_group)) {
> + pr_warn("iommu_tce: device %s is already in iommu group %d, skipping\n",
> + dev_name(dev),
> + iommu_group_id(dev->iommu_group));
> + return -EBUSY;
> + }
[snip]
> +static int __init tce_iommu_init(void)
> +{
> + struct pci_dev *pdev = NULL;
> +
> + BUILD_BUG_ON(PAGE_SIZE < IOMMU_PAGE_SIZE);
> +
> + for_each_pci_dev(pdev)
> + iommu_add_device(&pdev->dev);
> +
> + bus_register_notifier(&pci_bus_type, &tce_iommu_bus_nb);
> + return 0;
> +}
> +
> +subsys_initcall_sync(tce_iommu_init);
This is missing a check to see whether the appropriate hardware is
present. This file should also be renamed to something less generic, and
depend on a kconfig symbol more specific than CONFIG_PPC64.
When this is combined with CONFIG_FSL_PAMU on hardware with a PAMU, I get
a bunch of those "WARN_ON(dev->iommu_group)" dumps because PAMU already
got to them. Presumably without PAMU it silently (or with just pr_debug)
bails out at some other point.
-Scott
^ permalink raw reply
* Re: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
From: Gerhard Sittig @ 2013-12-12 22:25 UTC (permalink / raw)
To: Matteo Facchinetti
Cc: Scott Wood, Mike Turquette, Anatolij Gustschin, linuxppc-dev,
Detlev Zundel
In-Reply-To: <52A9E074.5080607@sirius-es.it>
On Thu, Dec 12, 2013 at 17:12 +0100, Matteo Facchinetti wrote:
>
> On 10/12/2013 14:11, Gerhard Sittig wrote:
> >this series improves the previously introduced common clock support for
> >MPC512x such that SoC variants 5123 and 5125 get addressed appropriately
> >(MPC5125 turned out to be rather different from MPC5121 than I perceived
> >before -- there is much more than "just two FECs and no MBX")
> Ohhh yesss..... welcome to hell! :-)
>
> I report also these differences:
>
> - I/O control module:
> to do integration with linux pin-muxing subsystem
>
> - GPIO module:
> controller is the same of the mpc5121 but with these differences:
> - 64 gpios divided in 2 banks
> - input only gpios are numbers form 0 to 3 of the first bank
> I'm finishing to write the patch... when done I'll post in ML
Yes, I've seen the 2x 32bits thing on MPC5125. Can't tell
whether one can just use two mpc8xxx-gpio nodes in the device
tree and be done.
MPC5121 has just one 32bits GPIO bank. And four of those pins
are "GPI only" as well. This may be identical to one of the two
MPC5125 banks.
> - NFC: one of the biggest unsolved mystery
> Is this ip-core used in others microcontrollers? Seems to be
> used only in mpc5125!!!
>
> >
> >Matteo, can you verify the crystal frequency in the DTS update, please?
> Crystal frequency is ok: 33MHz.
great
> >And that v3.13-rc kernels with v6 of the COMMON_CLK introduction for
> >MPC512x plus this series for MPC5125 operate your peripherals, both with
> >an updated device tree as well as with a former device tree that lacks
> >clock specs? Thank you! Setting CONFIG_COMMON_CLK_DEBUG=y in your
> >.config and eyeballing /sys/kernel/debug/clk/clk_summary will help you.
> >
> >
> I tested all on TWR board.
Thank you! I think this qualifies as Tested-by: then. :)
> In DTS, for the moment, have to comment out this block:
> - usb@3000 {
> - compatible = "fsl,mpc5121-usb2-dr";
> - reg = <0x3000 0x400>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> - interrupts = <43 0x8>;
> - dr_mode = "host";
> - phy_type = "ulpi";
> - clocks = <&clks MPC512x_CLK_USB1>;
> - clock-names = "ipg";
> - };
> Because USB controller pinout is not initialized correctly and when
> system boot, causes a kernel panic.
>
> For the rest, kernel works correctly. For MPC5125 the patches are OK.
>
> I also check clk_summary and all clocks values are OK (except for
> NFC clock value).
Since there is no user of the NFC block yet, I did not implement
the driver for the clock item. The list of clocks in debugfs
should completely lack an NFC entry since nothing was registered
with the CCF subsystem.
> I notice that there are missing clock like: gpio1, gpio2, fuse, dma,
> wdt, pmc, rtc.
> Is this OK or should be added?
Are there registers for those clock items? Haven't seen any when
flipping through the RM's clocks chapter. If there's no
(software controllable) gate or divider, then there's no clock
item in need of software support.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [V2 PATCH 3/3] powerpc: Fix Unaligned LE Floating Point Loads and Stores
From: Paul Mackerras @ 2013-12-12 21:19 UTC (permalink / raw)
To: Tom Musta; +Cc: linuxppc-dev
In-Reply-To: <52AA1DA0.80003@gmail.com>
On Thu, Dec 12, 2013 at 02:33:36PM -0600, Tom Musta wrote:
> On 12/12/2013 9:08 AM, Tom Musta wrote:
> > On 12/10/2013 10:57 PM, Paul Mackerras wrote:
> >> On Wed, Dec 11, 2013 at 02:54:40PM +1100, Paul Mackerras wrote:
> >
> >>> This breaks 32-bit big-endian (as well as making the code longer and
> >>> more complex).
> >>
> >> And in fact none of this code will get executed in little-endian mode
> >> anyway, since we still have this in the middle of emulate_step():
> >>
> >> /*
> >> * Following cases are for loads and stores, so bail out
> >> * if we're in little-endian mode.
> >> */
> >> if (regs->msr & MSR_LE)
> >> return 0;
> >>
> >> Paul.
> >>
> >
> > See patch 1/3 to explain how it becomes relevant in LE.
> >
> > I will take another look at the change.
> >
>
> It appears that patch 1/3 never got picked up, even though I thought Ben & I
> had worked through that.
>
> And I agree that the code could be simpler. I will work up a patch to address
> these two issues.
The other thing that's important for us to know is how you are testing
these changes. For something like this I'd like to see a description
of the tests you have done in the commit message.
I have been hacking on sstep.c pretty heavily myself recently, so we
will need to coordinate on the changes.
Paul.
^ permalink raw reply
* Re: [V2 PATCH 3/3] powerpc: Fix Unaligned LE Floating Point Loads and Stores
From: Tom Musta @ 2013-12-12 20:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <52A9D17E.3000809@gmail.com>
On 12/12/2013 9:08 AM, Tom Musta wrote:
> On 12/10/2013 10:57 PM, Paul Mackerras wrote:
>> On Wed, Dec 11, 2013 at 02:54:40PM +1100, Paul Mackerras wrote:
>
>>> This breaks 32-bit big-endian (as well as making the code longer and
>>> more complex).
>>
>> And in fact none of this code will get executed in little-endian mode
>> anyway, since we still have this in the middle of emulate_step():
>>
>> /*
>> * Following cases are for loads and stores, so bail out
>> * if we're in little-endian mode.
>> */
>> if (regs->msr & MSR_LE)
>> return 0;
>>
>> Paul.
>>
>
> See patch 1/3 to explain how it becomes relevant in LE.
>
> I will take another look at the change.
>
It appears that patch 1/3 never got picked up, even though I thought Ben & I
had worked through that.
And I agree that the code could be simpler. I will work up a patch to address
these two issues.
^ permalink raw reply
* Re: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
From: Scott Wood @ 2013-12-12 19:32 UTC (permalink / raw)
To: Sinan Akman
Cc: Mike Turquette, Detlev Zundel, Gerhard Sittig, Matteo Facchinetti,
Anatolij Gustschin, linuxppc-dev
In-Reply-To: <52A9F685.3040204@writeme.com>
On Thu, 2013-12-12 at 18:46 +0100, Sinan Akman wrote:
> Matteo Facchinetti wrote:
> > [...]
> > - NFC: one of the biggest unsolved mystery
> > Is this ip-core used in others microcontrollers? Seems to be used only
> > in mpc5125!!!
> I don't think that IP is used in any other FSL SoC. Scott can probably
> confirm this for us.
That's a different part of Freescale, so I don't know much about it, but
it looks pretty similar to MXC NAND. Back when those drivers were
submitted I tried to get the authors of each to work together to see if
a common driver made sense, but I got little response.
-Scott
^ permalink raw reply
* Re: [PATCH 2/4] kexec: Add IND_FLAGS macro
From: Geoff Levand @ 2013-12-12 19:33 UTC (permalink / raw)
To: Zhang Yanfei; +Cc: linuxppc-dev, kexec, Eric Biederman, Paul Mackerras
In-Reply-To: <52A912E3.1060802@cn.fujitsu.com>
Hi Zhang,
On Thu, 2013-12-12 at 09:35 +0800, Zhang Yanfei wrote:
> On 12/12/2013 08:18 AM, Geoff Levand wrote:
> > Add a new kexec preprocessor macro IND_FLAGS, which is the bitwise OR of
> > all the possible kexec IND_ kimage_entry indirection flags.
> >
> > Having this macro allows for simplified code in the prosessing of the
> > kexec kimage_entry items.
>
> Where? I didn't see any place you use this macro to help simplification.
As in powerpc, it allows constructions like this:
switch (entry & IND_FLAGS) {
case IND_DESTINATION:
...
case IND_INDIRECTION:
...
}
-Geoff
^ permalink raw reply
* Re: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
From: Sinan Akman @ 2013-12-12 17:46 UTC (permalink / raw)
To: Matteo Facchinetti
Cc: Mike Turquette, Detlev Zundel, Gerhard Sittig, Scott Wood,
Anatolij Gustschin, linuxppc-dev
In-Reply-To: <52A9E074.5080607@sirius-es.it>
Matteo Facchinetti wrote:
> [...]
> - NFC: one of the biggest unsolved mystery
> Is this ip-core used in others microcontrollers? Seems to be used only
> in mpc5125!!!
I don't think that IP is used in any other FSL SoC. Scott can probably
confirm this for us.
I did some digging on this NFC just to put enough things together
that I can erase and flash firmware using BDI3000 that is read and
executed properly when the boot flag is set.
Do you see any other anomalies with MPC5125 NFC ?
Thanks
Sinan Akman
^ permalink raw reply
* [PATCH] powerpc: Make unaligned accesses endian-safe for powerpc
From: Rajesh B Prathipati @ 2013-12-12 15:45 UTC (permalink / raw)
To: benh, paulus, linuxppc-dev, linux-kernel, anton
From: Rajesh B Prathipati <rprathip@linux.vnet.ibm.com>
The generic put_unaligned/get_unaligned macros were made endian-safe by
calling the appropriate endian dependent macros based on the endian type
of the powerpc processor.
Signed-off-by: Rajesh B Prathipati <rprathip@linux.vnet.ibm.com>
---
This patch applies to linux kernel version 3.12. This patch has been
tested and it fixes the problem with linux 3.12 USB stack.
--- linux/arch/powerpc/include/asm/unaligned.h.orig 2013-12-12
00:07:05.329073544 -0200
+++ linux/arch/powerpc/include/asm/unaligned.h 2013-12-11
23:56:52.918630238 -0200
@@ -4,13 +4,18 @@
#ifdef __KERNEL__
/*
- * The PowerPC can do unaligned accesses itself in big endian mode.
+ * The PowerPC can do unaligned accesses itself based on its endian mode.
*/
#include <linux/unaligned/access_ok.h>
#include <linux/unaligned/generic.h>
+#ifdef __LITTLE_ENDIAN__
+#define get_unaligned __get_unaligned_le
+#define put_unaligned __put_unaligned_le
+#else
#define get_unaligned __get_unaligned_be
#define put_unaligned __put_unaligned_be
+#endif
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_UNALIGNED_H */
^ permalink raw reply
* Re: [PATCH v1 0/4] powerpc/512x: update COMMON_CLK support for MPC5125
From: Matteo Facchinetti @ 2013-12-12 16:12 UTC (permalink / raw)
To: Gerhard Sittig, linuxppc-dev, Anatolij Gustschin, Mike Turquette
Cc: Scott Wood, Detlev Zundel
In-Reply-To: <1386681097-14126-1-git-send-email-gsi@denx.de>
On 10/12/2013 14:11, Gerhard Sittig wrote:
> this series improves the previously introduced common clock support for
> MPC512x such that SoC variants 5123 and 5125 get addressed appropriately
> (MPC5125 turned out to be rather different from MPC5121 than I perceived
> before -- there is much more than "just two FECs and no MBX")
Ohhh yesss..... welcome to hell! :-)
I report also these differences:
- I/O control module:
to do integration with linux pin-muxing subsystem
- GPIO module:
controller is the same of the mpc5121 but with these differences:
- 64 gpios divided in 2 banks
- input only gpios are numbers form 0 to 3 of the first bank
I'm finishing to write the patch... when done I'll post in ML
- NFC: one of the biggest unsolved mystery
Is this ip-core used in others microcontrollers? Seems to be
used only in mpc5125!!!
>
> Matteo, can you verify the crystal frequency in the DTS update, please?
Crystal frequency is ok: 33MHz.
> And that v3.13-rc kernels with v6 of the COMMON_CLK introduction for
> MPC512x plus this series for MPC5125 operate your peripherals, both with
> an updated device tree as well as with a former device tree that lacks
> clock specs? Thank you! Setting CONFIG_COMMON_CLK_DEBUG=y in your
> .config and eyeballing /sys/kernel/debug/clk/clk_summary will help you.
>
>
I tested all on TWR board.
In DTS, for the moment, have to comment out this block:
- usb@3000 {
- compatible = "fsl,mpc5121-usb2-dr";
- reg = <0x3000 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupts = <43 0x8>;
- dr_mode = "host";
- phy_type = "ulpi";
- clocks = <&clks MPC512x_CLK_USB1>;
- clock-names = "ipg";
- };
Because USB controller pinout is not initialized correctly and when
system boot, causes a kernel panic.
For the rest, kernel works correctly. For MPC5125 the patches are OK.
I also check clk_summary and all clocks values are OK (except for NFC
clock value).
I notice that there are missing clock like: gpio1, gpio2, fuse, dma,
wdt, pmc, rtc.
Is this OK or should be added?
Regards,
Matteo Facchinetti
Sirius Electronic Systems
^ permalink raw reply
* Re: [V2 PATCH 3/3] powerpc: Fix Unaligned LE Floating Point Loads and Stores
From: Tom Musta @ 2013-12-12 15:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20131211045728.GB9399@drongo>
On 12/10/2013 10:57 PM, Paul Mackerras wrote:
> On Wed, Dec 11, 2013 at 02:54:40PM +1100, Paul Mackerras wrote:
>> This breaks 32-bit big-endian (as well as making the code longer and
>> more complex).
>
> And in fact none of this code will get executed in little-endian mode
> anyway, since we still have this in the middle of emulate_step():
>
> /*
> * Following cases are for loads and stores, so bail out
> * if we're in little-endian mode.
> */
> if (regs->msr & MSR_LE)
> return 0;
>
> Paul.
>
See patch 1/3 to explain how it becomes relevant in LE.
I will take another look at the change.
^ permalink raw reply
* Re: [PATCH v2] spi/fsl-espi: Add Power Management support for eSPI controller
From: Mark Brown @ 2013-12-12 11:56 UTC (permalink / raw)
To: Hou Zhiqiang; +Cc: linuxppc-dev, Mingkai.Hu, scottwood, linux-spi
In-Reply-To: <1386824032-19198-1-git-send-email-b48286@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 196 bytes --]
On Thu, Dec 12, 2013 at 12:53:52PM +0800, Hou Zhiqiang wrote:
> Add PM support for eSPI controller using callback function suspend
> and resume in .driver.pm of platform_driver.
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* powerpc/powernv: Framework to log critical errors on powernv.
From: Deepthi Dharwar @ 2013-12-12 11:25 UTC (permalink / raw)
To: PowerPC email list, Benjamin Herrenschmidt
powerpc/powernv: Framework to log critical errors on powernv.
From: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
This patch provides error logging interfaces to report critical
powernv error logs to FSP.
All the required information to dump the error is collected
at POWERNV level through error log interfaces
and then pushed on to FSP.
Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/opal.h | 125 ++++++++++++++++++++++++
arch/powerpc/platforms/powernv/opal-elog.c | 59 +++++++++++
arch/powerpc/platforms/powernv/opal-wrappers.S | 1
3 files changed, 184 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index be404ea..b8d1dd4 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -134,6 +134,7 @@ extern int opal_enter_rtas(struct rtas_args *args,
#define OPAL_ELOG_ACK 73
#define OPAL_ELOG_RESEND 74
#define OPAL_ELOG_SIZE 75
+#define OPAL_ELOG_SEND 87
#ifndef __ASSEMBLY__
@@ -216,6 +217,122 @@ enum OpalPendingState {
OPAL_EVENT_PCI_ERROR = 0x200
};
+/* Classification of Error/Events reporting type classification
+ * Platform Events/Errors: Report Machine Check Interrupt
+ * INPUT_OUTPUT: Report all I/O related events/errors
+ * RESOURCE_DEALLOC: Hotplug events and errors
+ * MISC: Miscellanous error
+ * Field: error_events_type
+ */
+enum Error_Events {
+ OPAL_PLATFORM,
+ OPAL_INPUT_OUTPUT,
+ OPAL_RESOURCE_DEALLOC,
+ OPAL_MISC,
+};
+
+/* OPAL Subsystem IDs listed for reporting events/errors
+ * Field: subsystem_id
+ */
+
+#define OPAL_PROCESSOR_SUBSYSTEM 0x10
+#define OPAL_MEMORY_SUBSYSTEM 0x20
+#define OPAL_IO_SUBSYSTEM 0x30
+#define OPAL_IO_DEVICES 0x40
+#define OPAL_CEC_HARDWARE 0x50
+#define OPAL_POWER_COOLING 0x60
+#define OPAL_MISC_SUBSYSTEM 0x70
+#define OPAL_SURVEILLANCE_ERR 0x7A
+#define OPAL_PLATFORM_FIRMWARE 0x80
+#define OPAL_SOFTWARE 0x90
+#define OPAL_EXTERNAL_ENV 0xA0
+
+/* During reporting an event/error the following represents
+ * how serious the logged event/error is. (Severity)
+ * Field: event_sev
+ */
+#define OPAL_INFO 0x00
+#define OPAL_RECOVERED_ERR_GENERAL 0x10
+
+/* 0x2X series is to denote set of Predictive Error
+ * 0x20 Generic predictive error
+ * 0x21 Predictive error, degraded performance
+ * 0x22 Predictive error, fault may be corrected after reboot
+ * 0x23 Predictive error, fault may be corrected after reboot,
+ * degraded performance
+ * 0x24 Predictive error, loss of redundancy
+ */
+#define OPAL_PREDICTIVE_ERR_GENERAL 0x20
+#define OPAL_PREDICTIVE_ERR_DEGRADED_PERF 0x21
+#define OPAL_PREDICTIVE_ERR_FAULT_RECTIFY_REBOOT 0x22
+#define OPAL_PREDICTIVE_ERR_FAULT_RECTIFY_BOOT_DEGRADE_PERF 0x23
+#define OPAL_PREDICTIVE_ERR_LOSS_OF_REDUNDANCY 0x24
+
+/* 0x4X series for Unrecoverable Error
+ * 0x40 Generic Unrecoverable error
+ * 0x41 Unrecoverable error bypassed with degraded performance
+ * 0x44 Unrecoverable error bypassed with loss of redundancy
+ * 0x45 Unrecoverable error bypassed with loss of redundancy and performance
+ * 0x48 Unrecoverable error bypassed with loss of function
+ */
+#define OPAL_UNRECOVERABLE_ERR_GENERAL 0x40
+#define OPAL_UNRECOVERABLE_ERR_DEGRADE_PERF 0x41
+#define OPAL_UNRECOVERABLE_ERR_LOSS_REDUNDANCY 0x44
+#define OPAL_UNRECOVERABLE_ERR_LOSS_REDUNDANCY_PERF 0x45
+#define OPAL_UNRECOVERABLE_ERR_LOSS_OF_FUNCTION 0x48
+
+/* Event Sub-type
+ * This field provides additional information on the non-error
+ * event type
+ * Field: event_subtype
+ */
+#define OPAL_NA 0x00
+#define OPAL_MISCELLANEOUS_INFO_ONLY 0x01
+#define OPAL_PREV_REPORTED_ERR_RECTIFIED 0x10
+#define OPAL_SYS_RESOURCES_DECONFIG_BY_USER 0x20
+#define OPAL_SYS_RESOURCE_DECONFIG_PRIOR_ERR 0x21
+#define OPAL_RESOURCE_DEALLOC_EVENT_NOTIFY 0x22
+#define OPAL_CONCURRENT_MAINTENANCE_EVENT 0x40
+#define OPAL_CAPACITY_UPGRADE_EVENT 0x60
+#define OPAL_RESOURCE_SPARING_EVENT 0x70
+#define OPAL_DYNAMIC_RECONFIG_EVENT 0x80
+#define OPAL_NORMAL_SYS_PLATFORM_SHUTDOWN 0xD0
+#define OPAL_ABNORMAL_POWER_OFF 0xE0
+
+/* Max user dump size is 14K */
+#define OPAL_LOG_MAX_DUMP 14336
+
+/* Multiple user data sections */
+struct opal_usr_data_scn {
+ uint32_t tag;
+ uint16_t size;
+ uint16_t component_id;
+ char data_dump[4];
+};
+
+
+/* All the information regarding an error/event to be reported
+ * needs to populate this structure using pre-defined interfaces
+ * only
+ */
+struct opal_errorlog {
+
+ uint16_t component_id;
+ uint8_t error_events_type:3;
+ uint8_t subsystem_id;
+
+ uint8_t event_sev;
+ uint8_t event_subtype;
+ uint8_t usr_scn_count; /* User section count */
+ uint8_t elog_origin;
+
+ uint32_t usr_scn_size; /* User section size */
+ uint32_t reason_code;
+ uint32_t additional_info[4];
+
+ char usr_data_dump[OPAL_LOG_MAX_DUMP];
+};
+
/* Machine check related definitions */
enum OpalMCE_Version {
OpalMCE_V1 = 1,
@@ -667,6 +784,14 @@ int64_t opal_get_elog_size(uint64_t *log_id, size_t *size, uint64_t *elog_type);
int64_t opal_write_elog(uint64_t buffer, uint64_t size, uint64_t offset);
int64_t opal_send_ack_elog(uint64_t log_id);
void opal_resend_pending_logs(void);
+struct opal_errorlog *elog_create(uint8_t err_evt_type, uint16_t component_id,
+ uint8_t subsystem_id, uint8_t event_sev, uint8_t event_subtype,
+ uint32_t reason_code, uint32_t info0, uint32_t info1,
+ uint32_t info2, uint32_t info3);
+int update_user_dump(struct opal_errorlog *buf, unsigned char *data,
+ uint32_t tag, uint16_t size);
+void commit_errorlog_to_fsp(struct opal_errorlog *buf);
+int opal_commit_log_to_fsp(void *buf);
/* Internal functions */
extern int early_init_dt_scan_opal(unsigned long node, const char *uname, int depth, void *data);
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
index 58849d0..af8d385 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -16,13 +16,15 @@
#include <linux/fs.h>
#include <linux/vmalloc.h>
#include <linux/fcntl.h>
+#include <linux/mm.h>
#include <asm/uaccess.h>
#include <asm/opal.h>
/* Maximum size of a single log on FSP is 16KB */
#define OPAL_MAX_ERRLOG_SIZE 16384
+#define USR_CHAR_ARRAY_FIXED_SIZE 4
-/* maximu number of records powernv can hold */
+/* maximum number of records powernv can hold */
#define MAX_NUM_RECORD 128
struct opal_err_log {
@@ -272,6 +274,61 @@ static int init_err_log_buffer(void)
return 0;
}
+/* Interface to be used by POWERNV to push the logs to FSP via Sapphire */
+struct opal_errorlog *elog_create(uint8_t err_evt_type, uint16_t component_id,
+ uint8_t subsystem_id, uint8_t event_sev, uint8_t event_subtype,
+ uint32_t reason_code, uint32_t info0, uint32_t info1,
+ uint32_t info2, uint32_t info3)
+{
+ struct opal_errorlog *buf;
+
+ buf = kzalloc(sizeof(struct opal_errorlog), GFP_KERNEL);
+ if (!buf) {
+ printk(KERN_ERR "ELOG: failed to allocate memory.\n");
+ return -ENOMEM;
+ }
+
+ buf->error_events_type = err_evt_type;
+ buf->component_id = component_id;
+ buf->subsystem_id = subsystem_id;
+ buf->event_sev = event_sev;
+ buf->event_subtype = event_subtype;
+ buf->reason_code = reason_code;
+ buf->additional_info[0] = info0;
+ buf->additional_info[1] = info1;
+ buf->additional_info[2] = info2;
+ buf->additional_info[3] = info3;
+ return buf;
+}
+
+int update_user_dump(struct opal_errorlog *buf, unsigned char *data,
+ uint32_t tag, uint16_t size)
+{
+ char *buffer = (char *)buf->usr_data_dump + buf->usr_scn_size;
+ struct opal_usr_data_scn *tmp;
+
+ if ((buf->usr_scn_size + size) > OPAL_LOG_MAX_DUMP) {
+ printk(KERN_ERR "ELOG: Size of dump data overruns buffer");
+ return -1;
+ }
+
+ tmp = (struct opal_usr_data_scn *)buffer;
+ tmp->tag = tag;
+ tmp->size = size + sizeof(struct opal_usr_data_scn)
+ - USR_CHAR_ARRAY_FIXED_SIZE;
+ memcpy(tmp->data_dump, data, size);
+
+ buf->usr_scn_size += tmp->size;
+ buf->usr_scn_count++;
+ return 0;
+}
+
+void commit_errorlog_to_fsp(struct opal_errorlog *buf)
+{
+ opal_commit_log_to_fsp((void *)(vmalloc_to_pfn(buf) << PAGE_SHIFT));
+ kfree(buf);
+}
+
/* Initialize error logging */
static int __init opal_elog_init(void)
{
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 66def92..f0c5178 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -121,3 +121,4 @@ OPAL_CALL(opal_send_ack_elog, OPAL_ELOG_ACK);
OPAL_CALL(opal_get_elog_size, OPAL_ELOG_SIZE);
OPAL_CALL(opal_resend_pending_logs, OPAL_ELOG_RESEND);
OPAL_CALL(opal_write_elog, OPAL_ELOG_WRITE);
+OPAL_CALL(opal_commit_log_to_fsp, OPAL_ELOG_SEND);
^ permalink raw reply related
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