Re: [PATCH v2] powerpc/cache: add cache flush operation for various e500
On Mon, 2015-06-08 at 18:06 +0800, yuantian.t...@freescale.com wrote:
+
+_GLOBAL(flush_caches_e500v2)
+ mflr r0
+ bl flush_dcache_L1
+ mtlr r0
+ blr
+
+_GLOBAL(flush_caches_e500mc)
+_GLOBAL(flush_caches_e5500)
+ mflr r0
+ bl flush_dcache_L1
+ bl flush_backside_L2_cache
+ mtlr r0
+ blr
s/flush_caches/cpu_down_flush/g
+
+/* L1 Data Cache of e6500 contains no modified data, no flush is
required */
+_GLOBAL(flush_caches_e6500)
+ blr
diff --git a/arch/powerpc/kernel/cputable.c
b/arch/powerpc/kernel/cputable.c
index 60262fd..ed388c7 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -2021,6 +2021,7 @@ static struct cpu_spec __initdata cpu_specs[] =
{
.cpu_setup = __setup_cpu_e500v2,
.machine_check = machine_check_e500,
.platform = ppc8548,
+ .cpu_down_flush = flush_caches_e500v2,
},
#else
{ /* e500mc */
@@ -2040,6 +2041,7 @@ static struct cpu_spec __initdata cpu_specs[] =
{
.cpu_setup = __setup_cpu_e500mc,
.machine_check = machine_check_e500mc,
.platform = ppce500mc,
+ .cpu_down_flush = flush_caches_e500mc,
},
Please keep whitespace consistent with the rest of the structure.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/corenet: enable eSDHC
On Mon, 2015-06-08 at 05:12 -0500, Lu Yangbo-B47093 wrote: Thanks a lot, Scott. And now a patch was merged on git://git.linaro.org/people/ulf.hansson/mmc.git next branch to fix this issue. It should be no problem. Assuming that patch fixes it and gets pulled for 4.2, this config patch can go in for 4.3. That said, it would be nice if, apart from fixing the problem itself, the MMC code failed more gracefully instead of endlessly repeating and filling up the log/console. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 19/21] drivers/of: Support adding sub-tree
On Sun, 2015-06-07 at 08:54 +0100, Grant Likely wrote: IE. conceptually, what overlays do today is quite rooted around the idea of having a fixed base DT and some pre-compiled DTB overlays that get added/removed. The design completely ignore the idea of a FW that maintains a live tree which we want to keep in sync, which is what we want to do here, or what we could do with a live open firmware implementation. Right, which is exactly the reason for the changeset/overlay split. Overlays assume a fixed base, and that overlays are kind of like plug-in modules. changeset makes no such assumption. So you suggest we create a function that takes an fdt and an anchor as input, and expands that FDT below that anchor, but does so by using the changeset API under the hood ? Even that looks somewhat tricky (turn that bit of FDT into a pile of changeset actions), however, I can see how we could create a new function inside changeset to attach a subtree. Ie. of_attach_subtree() (which could have it's own reconfig action but we don't care that much yet), which takes an expanded subtree and an anchor, and calls of_attach_node() in effect for all nodes in there. We could then have a two pass mechanism in our hotplug code: - Expand the bit of fdt into a separate tree - Use of_attach_subtree to add that subtree to the main tree What do you think ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Generic kernel features that need architecture(powerpc) support
Hi, If there is anything wrong, please report it in this thread: https://marc.info/?t=14333295573 The meaning of entries in the tables is: | ok | # feature supported by the architecture |TODO| # feature not yet supported by the architecture | .. | # feature cannot be supported by the hardware # # Kernel feature support matrix of the 'powerpc' architecture: # time/ irq-time-acct: .. |HAVE_IRQ_TIME_ACCOUNTING # arch supports precise IRQ time accounting core/ BPF-JIT : ok |HAVE_BPF_JIT # arch supports BPF JIT optimizations core/ generic-idle-thread : ok | GENERIC_SMP_IDLE_THREAD # arch makes use of the generic SMP idle thread facility core/ jump-labels : ok |HAVE_ARCH_JUMP_LABEL # arch supports live patched, high efficiency branches core/ tracehook: ok | HAVE_ARCH_TRACEHOOK # arch supports tracehook (ptrace) register handling APIs debug/ gcov-profile-all : ok | ARCH_HAS_GCOV_PROFILE_ALL # arch supports whole-kernel GCOV code coverage profiling debug/ kgdb : ok | HAVE_ARCH_KGDB # arch supports the kGDB kernel debugger debug/ kprobes : ok |HAVE_KPROBES # arch supports live patched kernel probe debug/ kretprobes : ok | HAVE_KRETPROBES # arch supports kernel function-return probes debug/ uprobes : ok | ARCH_SUPPORTS_UPROBES # arch supports live patched user probes io/ dma-api-debug: ok | HAVE_DMA_API_DEBUG # arch supports DMA debug facilities io/ dma_map_attrs: ok | HAVE_DMA_ATTRS # arch provides dma_*map*_attrs() APIs io/ sg-chain : ok | ARCH_HAS_SG_CHAIN # arch supports chained scatter-gather lists locking/ lockdep : ok | LOCKDEP_SUPPORT # arch supports the runtime locking correctness debug facility perf/ kprobes-event: ok | HAVE_REGS_AND_STACK_ACCESS_API # arch supports kprobes with perf events sched/ numa-balancing : ok |ARCH_SUPPORTS_NUMA_BALANCING # arch supports NUMA balancing time/ arch-tick-broadcast : ok | ARCH_HAS_TICK_BROADCAST # arch provides tick_broadcast() time/ clockevents : ok | GENERIC_CLOCKEVENTS # arch support generic clock events time/ context-tracking : ok | HAVE_CONTEXT_TRACKING # arch supports context tracking for NO_HZ_FULL time/ modern-timekeeping : ok |!ARCH_USES_GETTIMEOFFSET # arch does not use arch_gettimeoffset() anymore time/ virt-cpuacct : ok |HAVE_VIRT_CPU_ACCOUNTING # arch supports precise virtual CPU time accounting vm/ ELF-ASLR : ok | ARCH_HAS_ELF_RANDOMIZE # arch randomizes the stack, heap and binary images of ELF binaries vm/ ioremap_prot : ok | HAVE_IOREMAP_PROT # arch has ioremap_prot() vm/ numa-memblock: ok | HAVE_MEMBLOCK_NODE_MAP # arch supports NUMA aware memblocks vm/ pmdp_splitting_flush : ok |__HAVE_ARCH_PMDP_SPLITTING_FLUSH # arch supports the pmdp_splitting_flush() VM API vm/ pte_special : ok | __HAVE_ARCH_PTE_SPECIAL # arch supports the pte_special()/pte_mkspecial() VM APIs vm/ THP : ok | HAVE_ARCH_TRANSPARENT_HUGEPAGE # arch supports transparent hugepages debug/ KASAN: TODO | HAVE_ARCH_KASAN # arch supports the KASAN runtime memory checker debug/ kprobes-on-ftrace: TODO | HAVE_KPROBES_ON_FTRACE # arch supports combined kprobes and ftrace live patching debug/ optprobes: TODO | HAVE_OPTPROBES # arch supports live patched optprobes debug/ stackprotector : TODO | HAVE_CC_STACKPROTECTOR # arch supports compiler driven stack overflow protection debug/ user-ret-profiler: TODO | HAVE_USER_RETURN_NOTIFIER # arch supports user-space return from system call profiler io/ dma-contiguous : TODO | HAVE_DMA_CONTIGUOUS # arch supports the DMA CMA (continuous memory allocator) lib/ strncasecmp : TODO | __HAVE_ARCH_STRNCASECMP # arch provides an optimized strncasecmp() function locking/ cmpxchg-local: TODO | HAVE_CMPXCHG_LOCAL # arch supports the this_cpu_cmpxchg() API locking/ queued-rwlocks : TODO | ARCH_USE_QUEUED_RWLOCKS # arch supports queued rwlocks locking/ queued-spinlocks : TODO |
Re: [PATCH v4 19/21] drivers/of: Support adding sub-tree
On Mon, Jun 8, 2015 at 9:57 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Sun, 2015-06-07 at 08:54 +0100, Grant Likely wrote: IE. conceptually, what overlays do today is quite rooted around the idea of having a fixed base DT and some pre-compiled DTB overlays that get added/removed. The design completely ignore the idea of a FW that maintains a live tree which we want to keep in sync, which is what we want to do here, or what we could do with a live open firmware implementation. Right, which is exactly the reason for the changeset/overlay split. Overlays assume a fixed base, and that overlays are kind of like plug-in modules. changeset makes no such assumption. So you suggest we create a function that takes an fdt and an anchor as input, and expands that FDT below that anchor, but does so by using the changeset API under the hood ? Even that looks somewhat tricky (turn that bit of FDT into a pile of changeset actions), however, I can see how we could create a new function inside changeset to attach a subtree. Ie. of_attach_subtree() (which could have it's own reconfig action but we don't care that much yet), which takes an expanded subtree and an anchor, and calls of_attach_node() in effect for all nodes in there. We could then have a two pass mechanism in our hotplug code: - Expand the bit of fdt into a separate tree - Use of_attach_subtree to add that subtree to the main tree What do you think ? I like that. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [lockdep] cpufreq/ppc: possible circular locking dependency detected
On Mon, 2015-06-08 at 18:45 +0300, Denis Kirjanov wrote:
Hi,
I see the following lockdep splat on my RackMac machine on boot:
I don't completely understand what lockdep is trying to tell us here...
I don't see the deadlock.
Ben.
[6.002593] Registering G5 CPU frequency driver
[6.011288] Frequency method: i2c/pfunc, Voltage method: i2c/pfunc
[6.023605] Low: 1800 Mhz, High: 2300 Mhz, Cur: 1800 MHz
[6.038022] ==
[6.042080] windfarm: CPUs control loops started.
[6.042084] wf_rm31: Backside control loop started.
[6.042086] wf_rm31: Slots control loop started.
[6.078644] [ INFO: possible circular locking dependency detected ]
[6.091149] 4.1.0-rc6-01265-g908e80d-dirty #15 Not tainted
[6.102083] ---
[6.114586] swapper/0/1 is trying to acquire lock:
[6.124136] (bus-mutex){+.+.+.}, at: [c004d450]
.pmac_i2c_open+0x30/0x100
[6.139933]
but task is already holding lock:
[6.151569] (policy-rwsem){+.+.+.}, at: [c0620bbc]
.__cpufreq_add_dev.isra.29+0x34c/0xad0
[6.170143]
which lock already depends on the new lock.
[6.186464]
the existing dependency chain (in reverse order) is:
[6.201401]
- #4 (policy-rwsem){+.+.+.}:
[6.210077][c00d6380] .lock_acquire+0x80/0x100
[6.222061][c07a411c] .down_write+0x6c/0x110
[6.233690][c0620bbc]
.__cpufreq_add_dev.isra.29+0x34c/0xad0
[6.248104][c0489dd8]
.subsys_interface_register+0xc8/0x120
[6.262336][c06215f8]
.cpufreq_register_driver+0x138/0x310
[6.276404][c0adeca8] .g5_cpufreq_init+0x9cc/0xa28
[6.289079][c000a714] .do_one_initcall+0xd4/0x270
[6.301577][c0aaa778] .kernel_init_freeable+0x190/0x270
[6.315120][c000b17c] .kernel_init+0x1c/0x120
[6.326928][c00095b4] .ret_from_kernel_thread+0x58/0xa4
[6.340467]
- #3 (subsys mutex#2){+.+.+.}:
[6.349149][c00d6380] .lock_acquire+0x80/0x100
[6.361130][c07a0ccc] .mutex_lock_nested+0xac/0x5a0
[6.373980][c048aff4] .bus_probe_device+0x44/0xf0
[6.386477][c0488318] .device_add+0x508/0x730
[6.398284][c048fb8c] .register_cpu+0xfc/0x150
[6.410266][c0aaf27c] .topology_init+0x108/0x1c0
[6.422595][c000a714] .do_one_initcall+0xd4/0x270
[6.435092][c0aaa778] .kernel_init_freeable+0x190/0x270
[6.448637][c000b17c] .kernel_init+0x1c/0x120
[6.460444][c00095b4] .ret_from_kernel_thread+0x58/0xa4
[6.473983]
- #2 (cpu_add_remove_lock){+.+.+.}:
[6.483536][c00d6380] .lock_acquire+0x80/0x100
[6.495517][c07a0ccc] .mutex_lock_nested+0xac/0x5a0
[6.508361][c00781ac] .cpu_maps_update_begin+0x1c/0x30
[6.521732][c0070220] .register_power_pmu+0xa0/0x128
[6.534752][c0abed50] .init_ppc970_pmu+0x6c/0x8c
[6.547081][c000a714] .do_one_initcall+0xd4/0x270
[6.559578][c0aaa698] .kernel_init_freeable+0xb0/0x270
[6.572950][c000b17c] .kernel_init+0x1c/0x120
[6.584758][c00095b4] .ret_from_kernel_thread+0x58/0xa4
[6.598297]
- #1 (host-mutex){+.+.+.}:
[6.606633][c00d6380] .lock_acquire+0x80/0x100
[6.618615][c07a0ccc] .mutex_lock_nested+0xac/0x5a0
[6.631458][c004d408] .kw_i2c_open+0x18/0x30
[6.643092][c004d4b4] .pmac_i2c_open+0x94/0x100
[6.655247][c0abb174] .smp_core99_probe+0x260/0x410
[6.668097][c0ab2f94] .smp_prepare_cpus+0x1ec/0x220
[6.680941][c0aaa670] .kernel_init_freeable+0x88/0x270
[6.694313][c000b17c] .kernel_init+0x1c/0x120
[6.706121][c00095b4] .ret_from_kernel_thread+0x58/0xa4
[6.719660]
- #0 (bus-mutex){+.+.+.}:
[6.727822][c00d5304] .__lock_acquire+0x1194/0x1b70
[6.740672][c00d6380] .lock_acquire+0x80/0x100
[6.752647][c07a0ccc] .mutex_lock_nested+0xac/0x5a0
[6.765497][c004d450] .pmac_i2c_open+0x30/0x100
[6.777652][c004da34] .pmac_i2c_do_begin+0x34/0x120
[6.790501][c00517e0] .pmf_call_one+0x50/0xd0
[6.802302][c06265ec] .g5_pfunc_switch_volt+0x2c/0xc0
[6.815501][c062659c] .g5_pfunc_switch_freq+0x1cc/0x1f0
[6.829040][c06262fc] .g5_cpufreq_target+0x2c/0x40
[6.841716][c061de40]
.__cpufreq_driver_target+0x230/0x400
[6.855783]
RE: [PATCH V2] QorIQ/TMU: add TMU node to device tree for QorIQ T104x
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, May 27, 2015 3:38 AM
To: Jia Hongtao-B38951
Cc: edubez...@gmail.com; linuxppc-dev@lists.ozlabs.org;
devicet...@vger.kernel.org; robh...@kernel.org; rui.zh...@intel.com
Subject: Re: [PATCH V2] QorIQ/TMU: add TMU node to device tree for QorIQ
T104x
On Tue, 2015-05-26 at 01:33 -0500, Jia Hongtao-B38951 wrote:
Hi Scott,
Eduardo indicated that calibration property should add fsl
prefix.
I updated the patch.
Any other comments?
If not I will send V3 soon.
Thanks.
I'd go with fsl,tmu-calibration rather than fsl,calibration but not a
big deal either way.
Thanks for the advice.
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-tmu-t104xsi.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-tmu-t104xsi.dtsi
new file mode 100644
index 000..d85c77d
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-tmu-t104xsi.dtsi
@@ -0,0 +1,82 @@
+/*
+ * QorIQ TMU device tree stub [ controller @ offset 0xf ]
+ *
+ * Copyright 2015 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or
without
+ * modification, are permitted provided that the following
conditions
are met:
+ * * Redistributions of source code must retain the above
copyright
+ * notice, this list of conditions and the following
disclaimer.
+ * * Redistributions in binary form must reproduce the above
copyright
+ * notice, this list of conditions and the following
disclaimer in
the
+ * documentation and/or other materials provided with the
distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or
promote
products
+ * derived from this software without specific prior written
permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the
terms of
the
+ * GNU General Public License (GPL) as published by the Free
Software
+ * Foundation, either version 2 of that License or (at your
option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS''
AND
ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
THE
IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE
ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE
LIABLE FOR
ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL
DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR
SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER
CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR
TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE
OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+tmu@f{
+ compatible = fsl,qoriq-tmu;
+ reg = 0xf 0x1000;
+ interrupts = 18 2 0 0;
+ calibration = 0x 0x000f
+ 0x0001 0x0017
+ 0x0002 0x001e
+ 0x0003 0x0026
+ 0x0004 0x002e
+ 0x0005 0x0035
+ 0x0006 0x003d
+ 0x0007 0x0044
+ 0x0008 0x004c
+ 0x0009 0x0053
+ 0x000a 0x005b
+ 0x000b 0x0062
+
+ 0x0001 0x0011
+ 0x00010001 0x0019
+ 0x00010002 0x0021
+ 0x00010003 0x002a
+ 0x00010004 0x0032
+ 0x00010005 0x003a
+ 0x00010006 0x0042
+ 0x00010007 0x004b
+ 0x00010008 0x0053
+ 0x00010009 0x005b
+ 0x0001000a 0x0063
+
+ 0x0002 0x0012
+ 0x00020001 0x001b
+ 0x00020002 0x0024
+ 0x00020003 0x002c
+ 0x00020004 0x0035
+ 0x00020005 0x003d
+ 0x00020006 0x0046
+ 0x00020007 0x004e
+ 0x00020008 0x0057
+
+ 0x0003 0x0009
+ 0x00030001 0x0011
+ 0x00030002 0x0019
+ 0x00030003 0x0021
+ 0x00030004 0x0029
+ 0x00030005 0x0031
+ 0x00030006 0x0039
+ 0x00030007 0x0041; };
diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
[PATCH v3] powerpc/cache: add cache flush operation for various e500
From: Tang Yuantian yuantian.t...@freescale.com
Various e500 core have different cache architecture, so they
need different cache flush operations. Therefore, add a callback
function cpu_flush_caches to the struct cpu_spec. The cache flush
operation for the specific kind of e500 is selected at init time.
The callback function will flush all caches inside the current cpu.
Signed-off-by: Chenhui Zhao chenhui.z...@freescale.com
Signed-off-by: Tang Yuantian yuantian.t...@feescale.com
---
v3:
- change all flush_caches to cpu_down_flush
- replace whitespace with tab
v2:
- remove some function's prefix __
- remove redundent CONFIG_PPC_E500MC micro
arch/powerpc/include/asm/cacheflush.h | 2 -
arch/powerpc/include/asm/cputable.h | 11 +++
arch/powerpc/kernel/asm-offsets.c | 3 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 112 ++
arch/powerpc/kernel/cputable.c| 4 ++
arch/powerpc/kernel/head_fsl_booke.S | 74
arch/powerpc/platforms/85xx/smp.c | 3 +-
7 files changed, 132 insertions(+), 77 deletions(-)
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index 30b35ff..729fde4 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -30,8 +30,6 @@ extern void flush_dcache_page(struct page *page);
#define flush_dcache_mmap_lock(mapping)do { } while (0)
#define flush_dcache_mmap_unlock(mapping) do { } while (0)
-extern void __flush_disable_L1(void);
-
extern void flush_icache_range(unsigned long, unsigned long);
extern void flush_icache_user_range(struct vm_area_struct *vma,
struct page *page, unsigned long addr,
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 6367b83..069 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -43,6 +43,13 @@ extern int machine_check_e500(struct pt_regs *regs);
extern int machine_check_e200(struct pt_regs *regs);
extern int machine_check_47x(struct pt_regs *regs);
+#if defined(CONFIG_E500)
+extern void cpu_down_flush_e500v2(void);
+extern void cpu_down_flush_e500mc(void);
+extern void cpu_down_flush_e5500(void);
+extern void cpu_down_flush_e6500(void);
+#endif
+
/* NOTE WELL: Update identify_cpu() if fields are added or removed! */
struct cpu_spec {
/* CPU is matched via (PVR pvr_mask) == pvr_value */
@@ -59,6 +66,10 @@ struct cpu_spec {
unsigned inticache_bsize;
unsigned intdcache_bsize;
+#if defined(CONFIG_E500)
+ /* flush caches inside the current cpu */
+ void (*cpu_down_flush)(void);
+#endif
/* number of performance monitor counters */
unsigned intnum_pmcs;
enum powerpc_pmc_type pmc_type;
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index 0034b6b..52efca9 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -373,6 +373,9 @@ int main(void)
DEFINE(CPU_SPEC_FEATURES, offsetof(struct cpu_spec, cpu_features));
DEFINE(CPU_SPEC_SETUP, offsetof(struct cpu_spec, cpu_setup));
DEFINE(CPU_SPEC_RESTORE, offsetof(struct cpu_spec, cpu_restore));
+#if defined(CONFIG_E500)
+ DEFINE(CPU_DOWN_FLUSH, offsetof(struct cpu_spec, cpu_down_flush));
+#endif
DEFINE(pbe_address, offsetof(struct pbe, address));
DEFINE(pbe_orig_address, offsetof(struct pbe, orig_address));
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index dddba3e..462aed9 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -13,11 +13,13 @@
*
*/
+#include asm/page.h
#include asm/processor.h
#include asm/cputable.h
#include asm/ppc_asm.h
#include asm/mmu-book3e.h
#include asm/asm-offsets.h
+#include asm/mpc85xx.h
_GLOBAL(__e500_icache_setup)
mfspr r0, SPRN_L1CSR1
@@ -233,3 +235,113 @@ _GLOBAL(__setup_cpu_e5500)
mtlrr5
blr
#endif
+
+/* flush L1 date cache, it can apply to e500v2, e500mc and e5500 */
+_GLOBAL(flush_dcache_L1)
+ mfmsr r10
+ wrteei 0
+
+ mfspr r3,SPRN_L1CFG0
+ rlwinm r5,r3,9,3 /* Extract cache block size */
+ twlgti r5,1/* Only 32 and 64 byte cache blocks
+* are currently defined.
+*/
+ li r4,32
+ subfic r6,r5,2 /* r6 = log2(1KiB / cache block size) -
+* log2(number of ways)
+*/
+ slw r5,r4,r5/* r5 = cache block size */
+
+ rlwinm r7,r3,0,0xff/* Extract number of KiB in the cache */
+ mulli r7,r7,13/* An 8-way cache will require 13
+
Re: [PATCH kernel v12 17/34] powerpc/spapr: vfio: Switch from iommu_table to new iommu_table_group
On Fri, Jun 05, 2015 at 04:35:09PM +1000, Alexey Kardashevskiy wrote: So far one TCE table could only be used by one IOMMU group. However IODA2 hardware allows programming the same TCE table address to multiple PE allowing sharing tables. This replaces a single pointer to a group in a iommu_table struct with a linked list of groups which provides the way of invalidating TCE cache for every PE when an actual TCE table is updated. This adds pnv_pci_link_table_and_group() and pnv_pci_unlink_table_and_group() helpers to manage the list. However without VFIO, it is still going to be a single IOMMU group per iommu_table. This changes iommu_add_device() to add a device to a first group from the group list of a table as it is only called from the platform init code or PCI bus notifier and at these moments there is only one group per table. This does not change TCE invalidation code to loop through all attached groups in order to simplify this patch and because it is not really needed in most cases. IODA2 is fixed in a later patch. This should cause no behavioural change. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru [aw: for the vfio related changes] Acked-by: Alex Williamson alex.william...@redhat.com Reviewed-by: Gavin Shan gws...@linux.vnet.ibm.com Reviewed-by: David Gibson da...@gibson.dropbear.id.au -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpjvfoOCwTjT.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v12 27/34] powerpc/powernv: Implement multilevel TCE tables
On Fri, Jun 05, 2015 at 04:35:19PM +1000, Alexey Kardashevskiy wrote: TCE tables might get too big in case of 4K IOMMU pages and DDW enabled on huge guests (hundreds of GB of RAM) so the kernel might be unable to allocate contiguous chunk of physical memory to store the TCE table. To address this, POWER8 CPU (actually, IODA2) supports multi-level TCE tables, up to 5 levels which splits the table into a tree of smaller subtables. This adds multi-level TCE tables support to pnv_pci_ioda2_table_alloc_pages() and pnv_pci_ioda2_table_free_pages() helpers. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru Reviewed-by: David Gibson da...@gibson.dropbear.id.au -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpY8A6lRarUl.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v12 32/34] powerpc/mmu: Add userspace-to-physical addresses translation cache
On Fri, Jun 05, 2015 at 04:35:24PM +1000, Alexey Kardashevskiy wrote: We are adding support for DMA memory pre-registration to be used in conjunction with VFIO. The idea is that the userspace which is going to run a guest may want to pre-register a user space memory region so it all gets pinned once and never goes away. Having this done, a hypervisor will not have to pin/unpin pages on every DMA map/unmap request. This is going to help with multiple pinning of the same memory. Another use of it is in-kernel real mode (mmu off) acceleration of DMA requests where real time translation of guest physical to host physical addresses is non-trivial and may fail as linux ptes may be temporarily invalid. Also, having cached host physical addresses (compared to just pinning at the start and then walking the page table again on every H_PUT_TCE), we can be sure that the addresses which we put into TCE table are the ones we already pinned. This adds a list of memory regions to mm_context_t. Each region consists of a header and a list of physical addresses. This adds API to: 1. register/unregister memory regions; 2. do final cleanup (which puts all pre-registered pages); 3. do userspace to physical address translation; 4. manage usage counters; multiple registration of the same memory is allowed (once per container). This implements 2 counters per registered memory region: - @mapped: incremented on every DMA mapping; decremented on unmapping; initialized to 1 when a region is just registered; once it becomes zero, no more mappings allowe; - @used: incremented on every register ioctl; decremented on unregister; unregistration is allowed for DMA mapped regions unless it is the very last reference. For the very last reference this checks that the region is still mapped and returns -EBUSY so the userspace gets to know that memory is still pinned and unregistration needs to be retried; @used remains 1. Host physical addresses are stored in vmalloc'ed array. In order to access these in the real mode (mmu off), there is a real_vmalloc_addr() helper. In-kernel acceleration patchset will move it from KVM to MMU code. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru Reviewed-by: David Gibson da...@gibson.dropbear.id.au -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpoMATttSE5e.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v12 33/34] vfio: powerpc/spapr: Register memory and define IOMMU v2
On Fri, Jun 05, 2015 at 04:35:25PM +1000, Alexey Kardashevskiy wrote: The existing implementation accounts the whole DMA window in the locked_vm counter. This is going to be worse with multiple containers and huge DMA windows. Also, real-time accounting would requite additional tracking of accounted pages due to the page size difference - IOMMU uses 4K pages and system uses 4K or 64K pages. Another issue is that actual pages pinning/unpinning happens on every DMA map/unmap request. This does not affect the performance much now as we spend way too much time now on switching context between guest/userspace/host but this will start to matter when we add in-kernel DMA map/unmap acceleration. This introduces a new IOMMU type for SPAPR - VFIO_SPAPR_TCE_v2_IOMMU. New IOMMU deprecates VFIO_IOMMU_ENABLE/VFIO_IOMMU_DISABLE and introduces 2 new ioctls to register/unregister DMA memory - VFIO_IOMMU_SPAPR_REGISTER_MEMORY and VFIO_IOMMU_SPAPR_UNREGISTER_MEMORY - which receive user space address and size of a memory region which needs to be pinned/unpinned and counted in locked_vm. New IOMMU splits physical pages pinning and TCE table update into 2 different operations. It requires: 1) guest pages to be registered first 2) consequent map/unmap requests to work only with pre-registered memory. For the default single window case this means that the entire guest (instead of 2GB) needs to be pinned before using VFIO. When a huge DMA window is added, no additional pinning will be required, otherwise it would be guest RAM + 2GB. The new memory registration ioctls are not supported by VFIO_SPAPR_TCE_IOMMU. Dynamic DMA window and in-kernel acceleration will require memory to be preregistered in order to work. The accounting is done per the user process. This advertises v2 SPAPR TCE IOMMU and restricts what the userspace can do with v1 or v2 IOMMUs. In order to support memory pre-registration, we need a way to track the use of every registered memory region and only allow unregistration if a region is not in use anymore. So we need a way to tell from what region the just cleared TCE was from. This adds a userspace view of the TCE table into iommu_table struct. It contains userspace address, one per TCE entry. The table is only allocated when the ownership over an IOMMU group is taken which means it is only used from outside of the powernv code (such as VFIO). As v2 IOMMU supports IODA2 and pre-IODA2 IOMMUs (which do not support DDW API), this creates a default DMA window for IODA2 for consistency. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru [aw: for the vfio related changes] Acked-by: Alex Williamson alex.william...@redhat.com Reviewed-by: David Gibson da...@gibson.dropbear.id.au -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpjshA681Tw7.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v12 26/34] powerpc/powernv/ioda2: Introduce pnv_pci_ioda2_set_window
On Fri, Jun 05, 2015 at 04:35:18PM +1000, Alexey Kardashevskiy wrote: This is a part of moving DMA window programming to an iommu_ops callback. pnv_pci_ioda2_set_window() takes an iommu_table_group as a first parameter (not pnv_ioda_pe) as it is going to be used as a callback for VFIO DDW code. This should cause no behavioural change. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru Reviewed-by: David Gibson da...@gibson.dropbear.id.au Reviewed-by: Gavin Shan gws...@linux.vnet.ibm.com --- Changes: v12: * removed comment from commit log about pnv_pci_ioda2_tvt_invalidate()/ pnv_pci_ioda2_invalidate_entire() Reviewed-by: David Gibson da...@gibson.dropbear.id.au -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpLUkZ99AV2G.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 01/42] PCI: Add pcibios_setup_bridge()
On Fri, Jun 05, 2015 at 02:44:32PM -0500, Bjorn Helgaas wrote:
On Thu, Jun 04, 2015 at 04:41:30PM +1000, Gavin Shan wrote:
Currently, PowerPC PowerNV platform utilizes ppc_md.pcibios_fixup(),
which is called for once after PCI probing and resource assignment
are completed, to allocate platform required resources for PCI devices:
PE#, IO and MMIO mapping, DMA address translation (TCE) table etc.
Obviously, it's not hotplug friendly.
The patch adds weak function pcibios_setup_bridge(), which is called
by pci_setup_bridge(). PowerPC PowerNV platform will reuse the function
to assign above platform required resources to newly added PCI devices,
in order to support PCI hotplug in subsequent patches.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
Acked-by: Bjorn Helgaas bhelg...@google.com
Thanks for your review, Bjorn.
Thanks,
Gavin
---
v5:
* Corrected subject as Bjorn suggested
* pci_setup_bridge() calls pcibios_setup_bridge() and __pci_setup_bridge()
---
drivers/pci/setup-bus.c | 5 +
include/linux/pci.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 4fd0cac..623dee3 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -693,11 +693,16 @@ static void __pci_setup_bridge(struct pci_bus *bus,
unsigned long type)
pci_write_config_word(bridge, PCI_BRIDGE_CONTROL, bus-bridge_ctl);
}
+void __weak pcibios_setup_bridge(struct pci_bus *bus, unsigned long type)
+{
+}
+
void pci_setup_bridge(struct pci_bus *bus)
{
unsigned long type = IORESOURCE_IO | IORESOURCE_MEM |
IORESOURCE_PREFETCH;
+pcibios_setup_bridge(bus, type);
__pci_setup_bridge(bus, type);
}
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 94bacfa..5aacd0a 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -811,6 +811,7 @@ void pci_stop_and_remove_bus_device_locked(struct
pci_dev *dev);
void pci_stop_root_bus(struct pci_bus *bus);
void pci_remove_root_bus(struct pci_bus *bus);
void pci_setup_cardbus(struct pci_bus *bus);
+void pcibios_setup_bridge(struct pci_bus *bus, unsigned long type);
void pci_sort_breadthfirst(void);
#define dev_is_pci(d) ((d)-bus == pci_bus_type)
#define dev_is_pf(d) ((dev_is_pci(d) ? to_pci_dev(d)-is_physfn : false))
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v12 09/34] vfio: powerpc/spapr: Move locked_vm accounting to helpers
On Fri, Jun 05, 2015 at 04:35:01PM +1000, Alexey Kardashevskiy wrote: There moves locked pages accounting to helpers. Later they will be reused for Dynamic DMA windows (DDW). This reworks debug messages to show the current value and the limit. This stores the locked pages number in the container so when unlocking the iommu table pointer won't be needed. This does not have an effect now but it will with the multiple tables per container as then we will allow attaching/detaching groups on fly and we may end up having a container with no group attached but with the counter incremented. While we are here, update the comment explaining why RLIMIT_MEMLOCK might be required to be bigger than the guest RAM. This also prints pid of the current process in pr_warn/pr_debug. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru [aw: for the vfio related changes] Acked-by: Alex Williamson alex.william...@redhat.com Reviewed-by: David Gibson da...@gibson.dropbear.id.au Reviewed-by: Gavin Shan gws...@linux.vnet.ibm.com --- Changes: v12: * added WARN_ON_ONCE() to decrement_locked_vm() for the sake of documentation Reviewed-by: David Gibson da...@gibson.dropbear.id.au -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgp30drJVBe55.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V8 10/10] selftests, powerpc: Add test for BHRB branch filters (HW SW)
On 06/08/2015 05:08 PM, Anshuman Khandual wrote: From: khand...@linux.vnet.ibm.com khand...@linux.vnet.ibm.com This should be Anshuman Khandual khand...@linux.vnet.ibm.com and it happened to couple of other patches in this series as well. I believe it got messed up in a test machine, will fix it next time around. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND v7 2/2] mmc: host: sdhci: Add support to disable SDR104/SDR50/DDR50 based on capability register 0.
[...] Can you test this patch on imx SoC ? (Your email have some format issue.) Yeah missed to sent in plain text mode. I have tested this patch and it does not break imx SoC. You can add my tag. Tested-by: Dong Aisheng aisheng.d...@freescale.com Thanks Dong !! However, it looks to me SDHCI_CAN_VDD_180 is only indicating the host VDD capabiliies, not IO voltage capability. I think Dong is correct. I don't think SDHCI_CAN_VDD_180 is not related to UHS modes at all. At least the name of the field (SDHCI_CAN_VDD_180) indicates it's about VDD/VCC, the core power and not the IO voltage. Are you sure on this ?? If SDHCI host VDD is 1.8V then the cards are also capable to operate at 1.8V ? Didn't understand what you mean by IO voltage capability SD3.0 cards require 1.8v IO voltage support. So should this bit affect SD3.0 support? The preset value resgister says that SDR modes requires 1.8V and we disable the modes based on capability or quirk. It requires 1.8V *IO voltage*, not VDD/VCC. [...] Kind regards Uffe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: powerpc/corenet: enable eSDHC
Thanks a lot, Scott. And now a patch was merged on git://git.linaro.org/people/ulf.hansson/mmc.git next branch to fix this issue. It should be no problem. From 5fd26c7ecb32082745b0bd33c8e35badd1cb5a91 Mon Sep 17 00:00:00 2001 From: Ulf Hansson ulf.hans...@linaro.org Date: Fri, 5 Jun 2015 11:40:08 +0200 Subject: [PATCH] mmc: sdhci: Restore behavior while creating OCR mask Commit 3a48edc4bd68 (mmc: sdhci: Use mmc core regulator infrastucture) changed the behavior for how to assign the ocr_avail mask for the mmc host. More precisely it started to mask the bits instead of assigning them. Restore the behavior, but also make it clear that an OCR mask created from an external regulator overrides the other ones. The OCR mask is determined by one of the following with this priority: 1. Supported ranges of external regulator if one supplies VDD 2. Host OCR mask if set by the driver (based on DT properties) 3. The capabilities reported by the controller itself Fixes: 3a48edc4bd68 (mmc: sdhci: Use mmc core regulator infrastucture) Cc: Tim Kryger tim.kry...@gmail.com Reported-by: Yangbo Lu yangbo...@freescale.com Signed-off-by: Ulf Hansson ulf.hans...@linaro.org Reviewed-by: Tim Kryger tim.kry...@gmail.com --- drivers/mmc/host/sdhci.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 1b4861d..706bb60 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -3256,13 +3256,14 @@ int sdhci_add_host(struct sdhci_host *host) SDHCI_MAX_CURRENT_MULTIPLIER; } - /* If OCR set by external regulators, use it instead */ + /* If OCR set by host, use it instead. */ + if (host-ocr_mask) + ocr_avail = host-ocr_mask; + + /* If OCR set by external regulators, give it highest prio. */ if (mmc-ocr_avail) ocr_avail = mmc-ocr_avail; - if (host-ocr_mask) - ocr_avail = host-ocr_mask; - mmc-ocr_avail = ocr_avail; mmc-ocr_avail_sdio = ocr_avail; if (host-ocr_avail_sdio) -- 2.1.0.27.g96db324 Best regards, Yangbo Lu -Original Message- From: Wood Scott-B07421 Sent: Saturday, May 30, 2015 8:04 AM To: Lu Yangbo-B47093 Cc: linuxppc-dev@lists.ozlabs.org; linux-...@vger.kernel.org Subject: Re: powerpc/corenet: enable eSDHC On Wed, May 06, 2015 at 02:29:08PM +0800, Yangbo Lu wrote: Signed-off-by: Yangbo Lu yangbo...@freescale.com --- arch/powerpc/configs/corenet32_smp_defconfig | 2 ++ arch/powerpc/configs/corenet64_smp_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig index ca7957b..17fb2e0 100644 --- a/arch/powerpc/configs/corenet32_smp_defconfig +++ b/arch/powerpc/configs/corenet32_smp_defconfig @@ -130,6 +130,8 @@ CONFIG_USB_OHCI_HCD_PPC_OF_LE=y CONFIG_USB_STORAGE=y CONFIG_MMC=y CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_PLTFM=y +CONFIG_MMC_SDHCI_OF_ESDHC=y CONFIG_EDAC=y CONFIG_EDAC_MM_EDAC=y CONFIG_EDAC_MPC85XX=y diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index 04737aa..4605a55 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -112,6 +112,8 @@ CONFIG_USB_EHCI_FSL=y CONFIG_USB_STORAGE=y CONFIG_MMC=y CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_PLTFM=y +CONFIG_MMC_SDHCI_OF_ESDHC=y CONFIG_EDAC=y CONFIG_EDAC_MM_EDAC=y CONFIG_RTC_CLASS=y With this on t4240rdb I'm continually spammed with: sdhci-esdhc ffe114000.sdhc: no support for card's volts mmc0: error -22 whilst initialising SD card sdhci-esdhc ffe114000.sdhc: no support for card's volts mmc0: error -22 whilst initialising SD card Releveant boot messages include: sdhci: Secure Digital Host Controller Interface driver sdhci: Copyright(c) Pierre Ossman sdhci-pltfm: SDHCI platform and OF driver helper sdhci-esdhc ffe114000.sdhc: No vmmc regulator found sdhci-esdhc ffe114000.sdhc: No vqmmc regulator found mmc0: SDHCI controller on ffe114000.sdhc [ffe114000.sdhc] using ADMA ... mmc0: error -22 whilst initialising SD card ... sdhci-esdhc ffe114000.sdhc: no support for card's volts mmc0: error -22 whilst initialising SD card -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/cache: add cache flush operation for various e500
From: Tang Yuantian yuantian.t...@freescale.com
Various e500 core have different cache architecture, so they
need different cache flush operations. Therefore, add a callback
function cpu_flush_caches to the struct cpu_spec. The cache flush
operation for the specific kind of e500 is selected at init time.
The callback function will flush all caches inside the current cpu.
Signed-off-by: Chenhui Zhao chenhui.z...@freescale.com
Signed-off-by: Tang Yuantian yuantian.t...@feescale.com
---
v2:
- remove some function's prefix __
- remove redundent CONFIG_PPC_E500MC micro
arch/powerpc/include/asm/cacheflush.h | 2 -
arch/powerpc/include/asm/cputable.h | 11 +++
arch/powerpc/kernel/asm-offsets.c | 3 +
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 114 +-
arch/powerpc/kernel/cputable.c| 4 ++
arch/powerpc/kernel/head_fsl_booke.S | 74 ---
arch/powerpc/platforms/85xx/smp.c | 3 +-
7 files changed, 133 insertions(+), 78 deletions(-)
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index 30b35ff..729fde4 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -30,8 +30,6 @@ extern void flush_dcache_page(struct page *page);
#define flush_dcache_mmap_lock(mapping)do { } while (0)
#define flush_dcache_mmap_unlock(mapping) do { } while (0)
-extern void __flush_disable_L1(void);
-
extern void flush_icache_range(unsigned long, unsigned long);
extern void flush_icache_user_range(struct vm_area_struct *vma,
struct page *page, unsigned long addr,
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 6367b83..43fffef 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -43,6 +43,13 @@ extern int machine_check_e500(struct pt_regs *regs);
extern int machine_check_e200(struct pt_regs *regs);
extern int machine_check_47x(struct pt_regs *regs);
+#if defined(CONFIG_E500)
+extern void flush_caches_e500v2(void);
+extern void flush_caches_e500mc(void);
+extern void flush_caches_e5500(void);
+extern void flush_caches_e6500(void);
+#endif
+
/* NOTE WELL: Update identify_cpu() if fields are added or removed! */
struct cpu_spec {
/* CPU is matched via (PVR pvr_mask) == pvr_value */
@@ -59,6 +66,10 @@ struct cpu_spec {
unsigned inticache_bsize;
unsigned intdcache_bsize;
+#if defined(CONFIG_E500)
+ /* flush caches inside the current cpu */
+ void (*cpu_down_flush)(void);
+#endif
/* number of performance monitor counters */
unsigned intnum_pmcs;
enum powerpc_pmc_type pmc_type;
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index 0034b6b..52efca9 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -373,6 +373,9 @@ int main(void)
DEFINE(CPU_SPEC_FEATURES, offsetof(struct cpu_spec, cpu_features));
DEFINE(CPU_SPEC_SETUP, offsetof(struct cpu_spec, cpu_setup));
DEFINE(CPU_SPEC_RESTORE, offsetof(struct cpu_spec, cpu_restore));
+#if defined(CONFIG_E500)
+ DEFINE(CPU_DOWN_FLUSH, offsetof(struct cpu_spec, cpu_down_flush));
+#endif
DEFINE(pbe_address, offsetof(struct pbe, address));
DEFINE(pbe_orig_address, offsetof(struct pbe, orig_address));
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index dddba3e..4c857a6a 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -1,7 +1,7 @@
/*
* This file contains low level CPU setup functions.
* Kumar Gala ga...@kernel.crashing.org
- * Copyright 2009 Freescale Semiconductor, Inc.
+ * Copyright 2009, 2015 Freescale Semiconductor, Inc.
*
* Based on cpu_setup_6xx code by
* Benjamin Herrenschmidt b...@kernel.crashing.org
@@ -13,11 +13,13 @@
*
*/
+#include asm/page.h
#include asm/processor.h
#include asm/cputable.h
#include asm/ppc_asm.h
#include asm/mmu-book3e.h
#include asm/asm-offsets.h
+#include asm/mpc85xx.h
_GLOBAL(__e500_icache_setup)
mfspr r0, SPRN_L1CSR1
@@ -233,3 +235,113 @@ _GLOBAL(__setup_cpu_e5500)
mtlrr5
blr
#endif
+
+/* flush L1 date cache, it can apply to e500v2, e500mc and e5500 */
+_GLOBAL(flush_dcache_L1)
+ mfmsr r10
+ wrteei 0
+
+ mfspr r3,SPRN_L1CFG0
+ rlwinm r5,r3,9,3 /* Extract cache block size */
+ twlgti r5,1/* Only 32 and 64 byte cache blocks
+* are currently defined.
+*/
+ li r4,32
+ subfic r6,r5,2 /* r6 = log2(1KiB / cache block size) -
+* log2(number of ways)
+*/
+ slw
Re: [PATCH RESEND v7 2/2] mmc: host: sdhci: Add support to disable SDR104/SDR50/DDR50 based on capability register 0.
On 8 June 2015 at 10:37, Ulf Hansson ulf.hans...@linaro.org wrote: [...] Can you test this patch on imx SoC ? (Your email have some format issue.) Yeah missed to sent in plain text mode. I have tested this patch and it does not break imx SoC. You can add my tag. Tested-by: Dong Aisheng aisheng.d...@freescale.com Thanks Dong !! However, it looks to me SDHCI_CAN_VDD_180 is only indicating the host VDD capabiliies, not IO voltage capability. I think Dong is correct. I don't think SDHCI_CAN_VDD_180 is not /s /is not /is related to UHS modes at all. At least the name of the field (SDHCI_CAN_VDD_180) indicates it's about VDD/VCC, the core power and not the IO voltage. Are you sure on this ?? If SDHCI host VDD is 1.8V then the cards are also capable to operate at 1.8V ? Didn't understand what you mean by IO voltage capability SD3.0 cards require 1.8v IO voltage support. So should this bit affect SD3.0 support? The preset value resgister says that SDR modes requires 1.8V and we disable the modes based on capability or quirk. It requires 1.8V *IO voltage*, not VDD/VCC. [...] Kind regards Uffe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v6] powerpc/powernv: Add poweroff (EPOW, DPO) events support for PowerNV platform
On 06/05/2015 03:31 AM, Michael Ellerman wrote:
On Thu, 2015-04-06 at 12:03:17 UTC, Vipin K Parashar wrote:
This patch adds support for FSP (Flexible Service Processor)
EPOW (Early Power Off Warning) and DPO (Delayed Power Off) events for
the PowerNV platform. EPOW events are generated by FSP due to various
critical system conditions that require system shutdown. A few examples
of these conditions are high ambient temperature or system running on
UPS power with low UPS battery. DPO event is generated in response to
admin initiated system shutdown request. Upon receipt of EPOW and DPO
events the host kernel invokes orderly_poweroff() for performing
graceful system shutdown.
Reviewed-by: Joel Stanley j...@jms.id.au
Reviewed-by: Vaibhav Jain vaib...@linux.vnet.ibm.com
Reviewed-by: Michael Ellerman m...@ellerman.id.au
Signed-off-by: Vipin K Parashar vi...@linux.vnet.ibm.com
Hi Vipin,
One issue, on mambo I'm seeing:
[666973573,3] OPAL: Called with bad token 105 !
opal-power: Existing DPO event detected.
reboot: Failed to start orderly shutdown: forcing the issue
reboot: Power down
[684431322,5] OPAL: Shutdown request type 0x0...
ie. at boot it shuts down immediately.
The problem is in here I think:
+ /* Check for DPO event */
+ rc = opal_get_dpo_status(opal_dpo_timeout);
+ if (rc != OPAL_WRONG_STATE) {
+ pr_info(Existing DPO event detected.\n);
+ return true;
+ }
Thanks for catching it. EPOW, DPO doesn't exist for BMC and thus we
shouldn't
be hitting this path on BMC/mambo. Bug exists below down where we check for
epow device-tree node . This bug got introduced with this version of
patch
when i renamed epow_dpo_supported flag with supported flag and re-organized
code. Will send out fix for this. Above if cond is also isn't prefect so
will fix it too
with new patch.
For FSP systems please use below FW patch to make it avoid notifications
which
doesn't cause EPOW. Its already in recent skiboot tree.
Commit id 1954251ca83b8a458193e629d15da06d00643ae8
https://patchwork.ozlabs.org/patch/472303/
This also makes me think you probably haven't tested this on a BMC machine?
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V8 03/10] powerpc, perf: Re organize BHRB processing
This patch cleans up some existing indentation problem in code and
re organizes the BHRB processing code with an helper function named
'update_branch_entry' making it more readable. This patch does not
change any functionality.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/perf/core-book3s.c | 107
1 file changed, 54 insertions(+), 53 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index ae61629..d10d2c1 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -412,11 +412,19 @@ static __u64 power_pmu_bhrb_to(u64 addr)
return target - (unsigned long)instr + addr;
}
+void update_branch_entry(struct cpu_hw_events *cpuhw,
+ int index, u64 from, u64 to, int pred)
+{
+ cpuhw-bhrb_entries[index].from = from;
+ cpuhw-bhrb_entries[index].to = to;
+ cpuhw-bhrb_entries[index].mispred = pred;
+ cpuhw-bhrb_entries[index].predicted = ~pred;
+}
+
/* Processing BHRB entries */
static void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
{
- u64 val;
- u64 addr;
+ u64 val, addr, tmp;
int r_index, u_index, pred;
r_index = 0;
@@ -427,63 +435,56 @@ static void power_pmu_bhrb_read(struct cpu_hw_events
*cpuhw)
if (!val)
/* Terminal marker: End of valid BHRB entries */
break;
- else {
- addr = val BHRB_EA;
- pred = val BHRB_PREDICTION;
- if (!addr)
- /* invalid entry */
- continue;
+ addr = val BHRB_EA;
+ pred = val BHRB_PREDICTION;
+
+ if (!addr)
+ /* invalid entry */
+ continue;
- /* Branches are read most recent first (ie. mfbhrb 0 is
-* the most recent branch).
-* There are two types of valid entries:
-* 1) a target entry which is the to address of a
-*computed goto like a blr,bctr,btar. The next
-*entry read from the bhrb will be branch
-*corresponding to this target (ie. the actual
-*blr/bctr/btar instruction).
-* 2) a from address which is an actual branch. If a
-*target entry proceeds this, then this is the
-*matching branch for that target. If this is not
-*following a target entry, then this is a branch
-*where the target is given as an immediate field
-*in the instruction (ie. an i or b form branch).
-*In this case we need to read the instruction from
-*memory to determine the target/to address.
+ /* Branches are read most recent first (ie. mfbhrb 0 is
+* the most recent branch).
+* There are two types of valid entries:
+* 1) a target entry which is the to address of a
+*computed goto like a blr,bctr,btar. The next
+*entry read from the bhrb will be branch
+*corresponding to this target (ie. the actual
+*blr/bctr/btar instruction).
+* 2) a from address which is an actual branch. If a
+*target entry proceeds this, then this is the
+*matching branch for that target. If this is not
+*following a target entry, then this is a branch
+*where the target is given as an immediate field
+*in the instruction (ie. an i or b form branch).
+*In this case we need to read the instruction from
+*memory to determine the target/to address.
+*/
+ if (val BHRB_TARGET) {
+ /* Target branches use two entries
+* (ie. computed gotos/XL form)
*/
+ tmp = addr;
+
+ /* Get from address in next entry */
+ val = read_bhrb(r_index++);
+ if (!val)
+ break;
+ addr = val BHRB_EA;
if (val BHRB_TARGET) {
- /* Target branches use two entries
-* (ie. computed gotos/XL form)
-*/
- cpuhw-bhrb_entries[u_index].to = addr;
- cpuhw-bhrb_entries[u_index].mispred = pred;
-
[PATCH V8 09/10] powerpc, perf: Enable privilege mode SW branch filters
From: khand...@linux.vnet.ibm.com khand...@linux.vnet.ibm.com
This patch enables privilege mode SW branch filters. Also modifies
POWER8 PMU branch filter configuration so that the privilege mode
branch filter implemented as part of base PMU event configuration
is reflected in bhrb filter mask. As a result, the SW will skip and
not try to process the privilege mode branch filters itself.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/perf_event_server.h | 3 +++
arch/powerpc/perf/core-book3s.c | 38 ++--
arch/powerpc/perf/power8-pmu.c | 13 --
3 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/perf_event_server.h
b/arch/powerpc/include/asm/perf_event_server.h
index cb7ca1a..23d68d3 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -85,6 +85,9 @@ extern unsigned long int read_bhrb(int n);
for ((x) = PERF_SAMPLE_BRANCH_USER; \
(x) PERF_SAMPLE_BRANCH_MAX; (x) = 1)
+#define POWER_ADDR_USER0
+#define POWER_ADDR_KERNEL 1
+
/*
* Only override the default definitions in include/linux/perf_event.h
* if we have hardware PMU support.
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 9a682c9..c151399 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -20,6 +20,7 @@
#include asm/firmware.h
#include asm/ptrace.h
#include asm/code-patching.h
+#include asm/cputable.h
#define BHRB_MAX_ENTRIES 32
#define BHRB_TARGET0x0002
@@ -465,10 +466,10 @@ static bool check_instruction(unsigned int *addr, u64
sw_filter)
* Access the instruction contained in the address and then check
* whether it complies with the applicable SW branch filters.
*/
-static bool keep_branch(u64 from, u64 sw_filter)
+static bool keep_branch(u64 from, u64 to, u64 sw_filter)
{
unsigned int instr;
- bool ret;
+ bool to_plm, ret, flag;
/*
* The from branch for every branch record has to go
@@ -478,6 +479,38 @@ static bool keep_branch(u64 from, u64 sw_filter)
if (sw_filter == 0)
return true;
+ to_plm = is_kernel_addr(to) ? POWER_ADDR_KERNEL : POWER_ADDR_USER;
+
+ /*
+* XXX: Applying the privilege mode SW branch filters first on
+* the 'TO' address creates an AND semantic with other SW branch
+* filters which are ORed with each other being applied on the
+* 'FROM' address there after.
+*/
+ if (sw_filter PERF_SAMPLE_BRANCH_PLM_ALL) {
+ flag = false;
+
+ if (sw_filter PERF_SAMPLE_BRANCH_USER) {
+ if (to_plm == POWER_ADDR_USER)
+ flag = true;
+ }
+
+ if (sw_filter PERF_SAMPLE_BRANCH_KERNEL) {
+ if (to_plm == POWER_ADDR_KERNEL)
+ flag = true;
+ }
+
+ if (sw_filter PERF_SAMPLE_BRANCH_HV) {
+ if (cpu_has_feature(CPU_FTR_HVMODE)) {
+ if (to_plm == POWER_ADDR_KERNEL)
+ flag = true;
+ }
+ }
+
+ if (!flag)
+ return false;
+ }
+
if (is_kernel_addr(from)) {
return check_instruction((unsigned int *) from, sw_filter);
} else {
@@ -567,6 +600,7 @@ static void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
/* Apply SW branch filters and drop the entry if required */
if (!keep_branch(cpuhw-bhrb_entries[u_index].from,
+ cpuhw-bhrb_entries[u_index].to,
cpuhw-bhrb_sw_filter))
u_index--;
u_index++;
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 8fccf6c..b56afc6 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -670,9 +670,19 @@ static u64 power8_bhrb_filter_map(u64 branch_sample_type,
u64 *bhrb_filter)
* filter configuration. BHRB is always recorded along with a
* regular PMU event. As the privilege state filter is handled
* in the basic PMC configuration of the accompanying regular
-* PMU event, we ignore any separate BHRB specific request.
+* PMU event, we ignore any separate BHRB specific request. But
+* this needs to be communicated with the branch filter mask.
*/
+ if (branch_sample_type PERF_SAMPLE_BRANCH_USER)
+ *bhrb_filter |= PERF_SAMPLE_BRANCH_USER;
+
+ if (branch_sample_type PERF_SAMPLE_BRANCH_KERNEL)
+ *bhrb_filter |= PERF_SAMPLE_BRANCH_KERNEL;
+
+
[PATCH V8 04/10] powerpc, perf: Re organize PMU based branch filter processing in POWER8
This patch does some code re-arrangements to make it clear that it ignores
any separate privilege level branch filter request and does not support
any combinations of HW PMU branch filters.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/perf/power8-pmu.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 396351d..a6c6a2c 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -656,8 +656,6 @@ static int power8_generic_events[] = {
static u64 power8_bhrb_filter_map(u64 branch_sample_type)
{
- u64 pmu_bhrb_filter = 0;
-
/* BHRB and regular PMU events share the same privilege state
* filter configuration. BHRB is always recorded along with a
* regular PMU event. As the privilege state filter is handled
@@ -665,21 +663,15 @@ static u64 power8_bhrb_filter_map(u64 branch_sample_type)
* PMU event, we ignore any separate BHRB specific request.
*/
- /* No branch filter requested */
- if (branch_sample_type PERF_SAMPLE_BRANCH_ANY)
- return pmu_bhrb_filter;
-
- /* Invalid branch filter options - HW does not support */
- if (branch_sample_type PERF_SAMPLE_BRANCH_ANY_RETURN)
- return -1;
+ /* Ignore user, kernel, hv bits */
+ branch_sample_type = ~PERF_SAMPLE_BRANCH_PLM_ALL;
- if (branch_sample_type PERF_SAMPLE_BRANCH_IND_CALL)
- return -1;
+ /* No branch filter requested */
+ if (branch_sample_type == PERF_SAMPLE_BRANCH_ANY)
+ return 0;
- if (branch_sample_type PERF_SAMPLE_BRANCH_ANY_CALL) {
- pmu_bhrb_filter |= POWER8_MMCRA_IFM1;
- return pmu_bhrb_filter;
- }
+ if (branch_sample_type == PERF_SAMPLE_BRANCH_ANY_CALL)
+ return POWER8_MMCRA_IFM1;
/* Every thing else is unsupported */
return -1;
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V8 01/10] powerpc, perf: Drop the branch sample when 'from' cannot be fetched
BHRB is a rolling buffer. Hence we might end up in a situation where
we have read one target address but when we try to read the next entry
indicating the from address of the targe, the buffer just overflows.
In this case, the captured from address will be zero which indicates
the end of the buffer.
This patch drops the entire branch record which would have otherwise
confused the user space tools.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/perf/core-book3s.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 12b6384..c246e65 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -452,7 +452,6 @@ static void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
*In this case we need to read the instruction from
*memory to determine the target/to address.
*/
-
if (val BHRB_TARGET) {
/* Target branches use two entries
* (ie. computed gotos/XL form)
@@ -463,6 +462,8 @@ static void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
/* Get from address in next entry */
val = read_bhrb(r_index++);
+ if (!val)
+ break;
addr = val BHRB_EA;
if (val BHRB_TARGET) {
/* Shouldn't have two targets in a
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V8 08/10] powerpc, perf: Change POWER8 PMU configuration to work with SW filters
The kernel now supports SW based branch filters for book3s systems with
some specific requirements while dealing with HW supported branch filters
in order to achieve overall OR semantics prevailing in perf branch stack
sampling framework. This patch adapts the BHRB branch filter configuration
to meet those protocols. POWER8 PMU can only handle one HW based branch
filter request at any point of time. For all other combinations PMU will
pass it on to the SW.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/perf/power8-pmu.c | 51 --
1 file changed, 44 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 5e17cb5..8fccf6c 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -656,6 +656,16 @@ static int power8_generic_events[] = {
static u64 power8_bhrb_filter_map(u64 branch_sample_type, u64 *bhrb_filter)
{
+ u64 x, pmu_bhrb_filter;
+
+ pmu_bhrb_filter = 0;
+ *bhrb_filter = 0;
+
+ if (branch_sample_type PERF_SAMPLE_BRANCH_ANY) {
+ *bhrb_filter = PERF_SAMPLE_BRANCH_ANY;
+ return pmu_bhrb_filter;
+ }
+
/* BHRB and regular PMU events share the same privilege state
* filter configuration. BHRB is always recorded along with a
* regular PMU event. As the privilege state filter is handled
@@ -666,15 +676,42 @@ static u64 power8_bhrb_filter_map(u64 branch_sample_type,
u64 *bhrb_filter)
/* Ignore user, kernel, hv bits */
branch_sample_type = ~PERF_SAMPLE_BRANCH_PLM_ALL;
- /* No branch filter requested */
- if (branch_sample_type == PERF_SAMPLE_BRANCH_ANY)
- return 0;
+ /*
+* POWER8 does not support ORing of PMU HW branch filters. Hence
+* if multiple branch filters are requested which may include filters
+* supported in PMU, still go ahead and clear the PMU based HW branch
+* filter component as in this case all the filters will be processed
+* in SW.
+*/
- if (branch_sample_type == PERF_SAMPLE_BRANCH_ANY_CALL)
- return POWER8_MMCRA_IFM1;
+ for_each_branch_sample_type(x) {
+ /* Ignore privilege branch filters */
+ if ((x == PERF_SAMPLE_BRANCH_USER)
+ || (x == PERF_SAMPLE_BRANCH_KERNEL)
+ || (x == PERF_SAMPLE_BRANCH_HV))
+ continue;
+
+ if (!(branch_sample_type x))
+ continue;
+
+ /* Supported individual PMU branch filters */
+ if (branch_sample_type PERF_SAMPLE_BRANCH_ANY_CALL) {
+ branch_sample_type = ~PERF_SAMPLE_BRANCH_ANY_CALL;
+ if (branch_sample_type) {
+ /* Multiple filters will be processed in SW */
+ pmu_bhrb_filter = 0;
+ *bhrb_filter = 0;
+ return pmu_bhrb_filter;
+ } else {
+ /* Individual filter will be processed in HW */
+ pmu_bhrb_filter |= POWER8_MMCRA_IFM1;
+ *bhrb_filter|= PERF_SAMPLE_BRANCH_ANY_CALL;
+ return pmu_bhrb_filter;
+ }
+ }
+ }
- /* Every thing else is unsupported */
- return -1;
+ return pmu_bhrb_filter;
}
static void power8_config_bhrb(u64 pmu_bhrb_filter)
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V8 06/10] powerpc, lib: Add new branch analysis support functions
Generic powerpc branch analysis support added in the code patching
library which will help the subsequent patch on SW based filtering
of branch records in perf.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/code-patching.h | 15
arch/powerpc/lib/code-patching.c | 66
2 files changed, 81 insertions(+)
diff --git a/arch/powerpc/include/asm/code-patching.h
b/arch/powerpc/include/asm/code-patching.h
index 840a550..0a6f0d8 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -22,6 +22,16 @@
#define BRANCH_SET_LINK0x1
#define BRANCH_ABSOLUTE0x2
+#define XL_FORM_LR 0x4C20
+#define XL_FORM_CTR 0x4C000420
+#define XL_FORM_TAR 0x4C000460
+
+#define BO_ALWAYS0x0280
+#define BO_CTR 0x0200
+#define BO_CRBI_OFF 0x0080
+#define BO_CRBI_ON 0x0180
+#define BO_CRBI_HINT 0x0040
+
unsigned int create_branch(const unsigned int *addr,
unsigned long target, int flags);
unsigned int create_cond_branch(const unsigned int *addr,
@@ -99,4 +109,9 @@ static inline unsigned long ppc_global_function_entry(void
*func)
#endif
}
+bool instr_is_return_branch(unsigned int instr);
+bool instr_is_conditional_branch(unsigned int instr);
+bool instr_is_func_call(unsigned int instr);
+bool instr_is_indirect_func_call(unsigned int instr);
+
#endif /* _ASM_POWERPC_CODE_PATCHING_H */
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index d5edbeb..15b7b88 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -87,6 +87,72 @@ static int instr_is_branch_bform(unsigned int instr)
return branch_opcode(instr) == 16;
}
+static int instr_is_branch_xlform(unsigned int instr)
+{
+ return branch_opcode(instr) == 19;
+}
+
+static int is_xlform_lr(unsigned int instr)
+{
+ return (instr XL_FORM_LR) == XL_FORM_LR;
+}
+
+static int is_bo_always(unsigned int instr)
+{
+ return (instr BO_ALWAYS) == BO_ALWAYS;
+}
+
+static int is_branch_link_set(unsigned int instr)
+{
+ return (instr BRANCH_SET_LINK) == BRANCH_SET_LINK;
+}
+
+bool instr_is_return_branch(unsigned int instr)
+{
+ /*
+* Conditional and unconditional branch to LR register
+* without seting the link register.
+*/
+ if (is_xlform_lr(instr) !is_branch_link_set(instr))
+ return true;
+
+ return false;
+}
+
+bool instr_is_conditional_branch(unsigned int instr)
+{
+ /* I-form instruction - excluded */
+ if (instr_is_branch_iform(instr))
+ return false;
+
+ /* B-form or XL-form instruction */
+ if (instr_is_branch_bform(instr) || instr_is_branch_xlform(instr)) {
+
+ /* Not branch always */
+ if (!is_bo_always(instr))
+ return true;
+ }
+ return false;
+}
+
+bool instr_is_func_call(unsigned int instr)
+{
+ /* LR should be set */
+ if (is_branch_link_set(instr))
+ return true;
+
+ return false;
+}
+
+bool instr_is_indirect_func_call(unsigned int instr)
+{
+ /* XL-form instruction with LR set */
+ if (instr_is_branch_xlform(instr) is_branch_link_set(instr))
+ return true;
+
+ return false;
+}
+
int instr_is_relative_branch(unsigned int instr)
{
if (instr BRANCH_ABSOLUTE)
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V8 02/10] powerpc, perf: Restore privillege level filter support for BHRB
From: khand...@linux.vnet.ibm.com khand...@linux.vnet.ibm.com
'commit 9de5cb0f6df8 (powerpc/perf: Add per-event excludes on Power8)'
broke the PMU based BHRB privilege level filter. BHRB depends on the
same MMCR0 bits for privilege level filter which was used to freeze all
the PMCs as a group. Once we moved to individual event based privilege
filters through MMCR2 register on POWER8, event associated privilege
filters are no longer applicable to the BHRB captured branches.
This patch solves the problem by restoring to the previous method of
privilege level filters for the event in case BHRB based branch stack
sampling is requested. This patch also changes 'check_excludes' for
the same reason.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/perf/core-book3s.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index c246e65..ae61629 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -930,7 +930,7 @@ static int power_check_constraints(struct cpu_hw_events
*cpuhw,
* added events.
*/
static int check_excludes(struct perf_event **ctrs, unsigned int cflags[],
- int n_prev, int n_new)
+ int n_prev, int n_new, int bhrb_users)
{
int eu = 0, ek = 0, eh = 0;
int i, n, first;
@@ -941,7 +941,7 @@ static int check_excludes(struct perf_event **ctrs,
unsigned int cflags[],
* don't need to do any of this logic. NB. This assumes no PMU has both
* per event exclude and limited PMCs.
*/
- if (ppmu-flags PPMU_ARCH_207S)
+ if ((ppmu-flags PPMU_ARCH_207S) !bhrb_users)
return 0;
n = n_prev + n_new;
@@ -1259,7 +1259,7 @@ static void power_pmu_enable(struct pmu *pmu)
goto out;
}
- if (!(ppmu-flags PPMU_ARCH_207S)) {
+ if (!(ppmu-flags PPMU_ARCH_207S) || cpuhw-bhrb_users) {
/*
* Add in MMCR0 freeze bits corresponding to the attr.exclude_*
* bits for the first event. We have already checked that all
@@ -1284,7 +1284,7 @@ static void power_pmu_enable(struct pmu *pmu)
mtspr(SPRN_MMCR1, cpuhw-mmcr[1]);
mtspr(SPRN_MMCR0, (cpuhw-mmcr[0] ~(MMCR0_PMC1CE | MMCR0_PMCjCE))
| MMCR0_FC);
- if (ppmu-flags PPMU_ARCH_207S)
+ if ((ppmu-flags PPMU_ARCH_207S) !cpuhw-bhrb_users)
mtspr(SPRN_MMCR2, cpuhw-mmcr[3]);
/*
@@ -1436,7 +1436,8 @@ static int power_pmu_add(struct perf_event *event, int
ef_flags)
if (cpuhw-group_flag PERF_EVENT_TXN)
goto nocheck;
- if (check_excludes(cpuhw-event, cpuhw-flags, n0, 1))
+ if (check_excludes(cpuhw-event, cpuhw-flags,
+ n0, 1, cpuhw-bhrb_users))
goto out;
if (power_check_constraints(cpuhw, cpuhw-events, cpuhw-flags, n0 + 1))
goto out;
@@ -1615,7 +1616,7 @@ static int power_pmu_commit_txn(struct pmu *pmu)
return -EAGAIN;
cpuhw = this_cpu_ptr(cpu_hw_events);
n = cpuhw-n_events;
- if (check_excludes(cpuhw-event, cpuhw-flags, 0, n))
+ if (check_excludes(cpuhw-event, cpuhw-flags, 0, n, cpuhw-bhrb_users))
return -EAGAIN;
i = power_check_constraints(cpuhw, cpuhw-events, cpuhw-flags, n);
if (i 0)
@@ -1828,10 +1829,12 @@ static int power_pmu_event_init(struct perf_event
*event)
events[n] = ev;
ctrs[n] = event;
cflags[n] = flags;
- if (check_excludes(ctrs, cflags, n, 1))
+ cpuhw = get_cpu_var(cpu_hw_events);
+ if (check_excludes(ctrs, cflags, n, 1, cpuhw-bhrb_users)) {
+ put_cpu_var(cpu_hw_events);
return -EINVAL;
+ }
- cpuhw = get_cpu_var(cpu_hw_events);
err = power_check_constraints(cpuhw, events, cflags, n + 1);
if (has_branch_stack(event)) {
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V8 07/10] powerpc, perf: Enable SW filtering in branch stack sampling framework
This patch enables SW based post processing of BHRB captured branches
to be able to meet more user defined branch filtration criteria in perf
branch stack sampling framework. These changes increase the number of
branch filters and their valid combinations on any powerpc64 server
platform with BHRB support. Find the summary of code changes here.
(1) struct cpu_hw_event
Introduced two new variables track various filter values and mask
(a) bhrb_sw_filter Tracks SW implemented branch filter flags
(b) bhrb_filter Tracks both (SW and HW) branch filter flags
(2) Event creation
Kernel will figure out supported BHRB branch filters through a PMU
call back 'bhrb_filter_map'. This function will find out how many of
the requested branch filters can be supported in the PMU HW. It will
not try to invalidate any branch filter combinations. Event creation
will not error out because of lack of HW based branch filters.
Meanwhile it will track the overall supported branch filters in the
'bhrb_filter' variable.
Once the PMU call back returns kernel will process the user branch
filter request against available SW filters (bhrb_sw_filter_map) while
looking at the 'bhrb_filter'. During this phase all the branch filters
which are still pending from the user requested list will have to be
supported in SW failing which the event creation will error out.
(3) SW branch filter
During the BHRB data capture inside the PMU interrupt context, each
of the captured 'perf_branch_entry.from' will be checked for compliance
with applicable SW branch filters. If the entry does not conform to the
filter requirements, it will be discarded from the final perf branch
stack buffer.
(4) Supported SW based branch filters
(a) PERF_SAMPLE_BRANCH_ANY_RETURN
(b) PERF_SAMPLE_BRANCH_IND_CALL
(c) PERF_SAMPLE_BRANCH_ANY_CALL
(d) PERF_SAMPLE_BRANCH_COND
Please refer the patch to understand the classification of instructions
into these branch filter categories.
(5) Multiple branch filter semantics
Book3 sever implementation follows the same OR semantics (as implemented
in x86) while dealing with multiple branch filters at any point of time.
SW branch filter analysis is carried on the data set captured in the PMU
HW. So the resulting set of data (after applying the SW filters) will
inherently be an AND with the HW captured set. Hence any combination of
HW and SW branch filters will be invalid. HW based branch filters are
more efficient and faster compared to SW implemented branch filters. So
at first the PMU should decide whether it can support all the requested
branch filters itself or not. In case it can support all the branch
filters in an OR manner, we dont apply any SW branch filter on top of the
HW captured set (which is the final set). This preserves the OR semantic
of multiple branch filters as required. But in case where the PMU cannot
support all the requested branch filters in an OR manner, it should not
apply any it's filters and leave it upto the SW to handle them all. Its
the PMU code's responsibility to uphold this protocol to be able to
conform to the overall OR semantic of perf branch stack sampling framework.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/perf_event_server.h | 7 +-
arch/powerpc/perf/core-book3s.c | 188 ++-
arch/powerpc/perf/power8-pmu.c | 2 +-
3 files changed, 191 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/perf_event_server.h
b/arch/powerpc/include/asm/perf_event_server.h
index 8146221..cb7ca1a 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -38,7 +38,8 @@ struct power_pmu {
unsigned long *valp);
int (*get_alternatives)(u64 event_id, unsigned int flags,
u64 alt[]);
- u64 (*bhrb_filter_map)(u64 branch_sample_type);
+ u64 (*bhrb_filter_map)(u64 branch_sample_type,
+ u64 *bhrb_filter);
void(*config_bhrb)(u64 pmu_bhrb_filter);
void(*disable_pmc)(unsigned int pmc, unsigned long mmcr[]);
int (*limited_pmc_event)(u64 event_id);
@@ -80,6 +81,10 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
extern unsigned long perf_instruction_pointer(struct pt_regs *regs);
extern unsigned long int read_bhrb(int n);
+#define for_each_branch_sample_type(x) \
+ for ((x) = PERF_SAMPLE_BRANCH_USER; \
+ (x) PERF_SAMPLE_BRANCH_MAX; (x) = 1)
+
/*
* Only override the default definitions in include/linux/perf_event.h
* if we have hardware PMU support.
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 080b038..9a682c9 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -53,6 +53,8 @@
[PATCH V8 10/10] selftests, powerpc: Add test for BHRB branch filters (HW SW)
From: khand...@linux.vnet.ibm.com khand...@linux.vnet.ibm.com
This patch adds a test for verifying that all the branch stack
sampling filters supported on powerpc works correctly. It also
adds some assembly helper functions in this regard. This patch
extends the generic event description to handle kernel mapped
ring buffers.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
tools/testing/selftests/powerpc/pmu/Makefile | 11 +-
tools/testing/selftests/powerpc/pmu/bhrb/Makefile | 13 +
.../selftests/powerpc/pmu/bhrb/bhrb_filters.c | 513 +
.../selftests/powerpc/pmu/bhrb/bhrb_filters.h | 16 +
.../selftests/powerpc/pmu/bhrb/bhrb_filters_asm.S | 260 +++
tools/testing/selftests/powerpc/pmu/event.h| 5 +
6 files changed, 816 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/selftests/powerpc/pmu/bhrb/Makefile
create mode 100644 tools/testing/selftests/powerpc/pmu/bhrb/bhrb_filters.c
create mode 100644 tools/testing/selftests/powerpc/pmu/bhrb/bhrb_filters.h
create mode 100644 tools/testing/selftests/powerpc/pmu/bhrb/bhrb_filters_asm.S
diff --git a/tools/testing/selftests/powerpc/pmu/Makefile
b/tools/testing/selftests/powerpc/pmu/Makefile
index a9099d9..2e103fd 100644
--- a/tools/testing/selftests/powerpc/pmu/Makefile
+++ b/tools/testing/selftests/powerpc/pmu/Makefile
@@ -4,7 +4,7 @@ noarg:
TEST_PROGS := count_instructions l3_bank_test per_event_excludes
EXTRA_SOURCES := ../harness.c event.c lib.c
-all: $(TEST_PROGS) ebb
+all: $(TEST_PROGS) ebb bhrb
$(TEST_PROGS): $(EXTRA_SOURCES)
@@ -18,25 +18,32 @@ DEFAULT_RUN_TESTS := $(RUN_TESTS)
override define RUN_TESTS
$(DEFAULT_RUN_TESTS)
$(MAKE) -C ebb run_tests
+ $(MAKE) -C bhrb run_tests
endef
DEFAULT_EMIT_TESTS := $(EMIT_TESTS)
override define EMIT_TESTS
$(DEFAULT_EMIT_TESTS)
$(MAKE) -s -C ebb emit_tests
+ $(MAKE) -s -C bhrb emit_tests
endef
DEFAULT_INSTALL_RULE := $(INSTALL_RULE)
override define INSTALL_RULE
$(DEFAULT_INSTALL_RULE)
$(MAKE) -C ebb install
+ $(MAKE) -C bhrb install
endef
clean:
rm -f $(TEST_PROGS) loop.o
$(MAKE) -C ebb clean
+ $(MAKE) -C bhrb clean
ebb:
$(MAKE) -k -C $@ all
-.PHONY: all run_tests clean ebb
+bhrb:
+ $(MAKE) -k -C $@ all
+
+.PHONY: all run_tests clean ebb bhrb
diff --git a/tools/testing/selftests/powerpc/pmu/bhrb/Makefile
b/tools/testing/selftests/powerpc/pmu/bhrb/Makefile
new file mode 100644
index 000..61c032a
--- /dev/null
+++ b/tools/testing/selftests/powerpc/pmu/bhrb/Makefile
@@ -0,0 +1,13 @@
+noarg:
+ $(MAKE) -C ../../
+
+TEST_PROGS := bhrb_filters
+
+all: $(TEST_PROGS)
+
+$(TEST_PROGS): ../../harness.c ../event.c ../lib.c bhrb_filters_asm.S
+
+include ../../../lib.mk
+
+clean:
+ rm -f $(TEST_PROGS)
diff --git a/tools/testing/selftests/powerpc/pmu/bhrb/bhrb_filters.c
b/tools/testing/selftests/powerpc/pmu/bhrb/bhrb_filters.c
new file mode 100644
index 000..13e6b72
--- /dev/null
+++ b/tools/testing/selftests/powerpc/pmu/bhrb/bhrb_filters.c
@@ -0,0 +1,513 @@
+/*
+ * BHRB filter test (HW SW)
+ *
+ * Copyright 2015 Anshuman Khandual, IBM Corporation.
+ *
+ * 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.
+ */
+#include unistd.h
+#include stdio.h
+#include stdlib.h
+#include signal.h
+#include poll.h
+#include sys/shm.h
+#include sys/types.h
+#include sys/wait.h
+#include sys/mman.h
+
+#include bhrb_filters.h
+#include utils.h
+#include ../event.h
+#include ../lib.h
+
+/* Fetched address counts */
+#define ALL_MAX32
+#define CALL_MAX 12
+#define RET_MAX10
+#define COND_MAX 8
+#define IND_MAX4
+
+/* Test tunables */
+#define LOOP_COUNT 10
+#define SAMPLE_PERIOD 1
+
+static int branch_sample_type;
+static int branch_test_set[27] = {
+ PERF_SAMPLE_BRANCH_ANY_CALL,/* Single filters */
+ PERF_SAMPLE_BRANCH_ANY_RETURN,
+ PERF_SAMPLE_BRANCH_COND,
+ PERF_SAMPLE_BRANCH_IND_CALL,
+ PERF_SAMPLE_BRANCH_ANY,
+
+ PERF_SAMPLE_BRANCH_ANY_CALL | /* Double filters */
+ PERF_SAMPLE_BRANCH_ANY_RETURN,
+ PERF_SAMPLE_BRANCH_ANY_CALL |
+ PERF_SAMPLE_BRANCH_COND,
+ PERF_SAMPLE_BRANCH_ANY_CALL |
+ PERF_SAMPLE_BRANCH_IND_CALL,
+ PERF_SAMPLE_BRANCH_ANY_CALL |
+ PERF_SAMPLE_BRANCH_ANY,
+
+ PERF_SAMPLE_BRANCH_ANY_RETURN |
+ PERF_SAMPLE_BRANCH_COND,
+ PERF_SAMPLE_BRANCH_ANY_RETURN |
+ PERF_SAMPLE_BRANCH_IND_CALL,
+ PERF_SAMPLE_BRANCH_ANY_RETURN |
+
[PATCH V8 05/10] powerpc, perf: Change the name of HW PMU branch filter tracking variable
This patch simply changes the name of the variable from 'bhrb_filter' to
'bhrb_hw_filter' in order to add one more variable which will track SW
filters in generic powerpc book3s code which will be implemented in the
subsequent patch. This patch does not change any functionality.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/perf/core-book3s.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index d10d2c1..080b038 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -52,7 +52,7 @@ struct cpu_hw_events {
int n_txn_start;
/* BHRB bits */
- u64 bhrb_filter;/* BHRB HW branch
filter */
+ u64 bhrb_hw_filter; /* BHRB HW filter */
int bhrb_users;
void*bhrb_context;
struct perf_branch_stack bhrb_stack;
@@ -1346,7 +1346,7 @@ static void power_pmu_enable(struct pmu *pmu)
mb();
if (cpuhw-bhrb_users)
- ppmu-config_bhrb(cpuhw-bhrb_filter);
+ ppmu-config_bhrb(cpuhw-bhrb_hw_filter);
write_mmcr0(cpuhw, mmcr0);
@@ -1454,7 +1454,7 @@ nocheck:
out:
if (has_branch_stack(event)) {
power_pmu_bhrb_enable(event);
- cpuhw-bhrb_filter = ppmu-bhrb_filter_map(
+ cpuhw-bhrb_hw_filter = ppmu-bhrb_filter_map(
event-attr.branch_sample_type);
}
@@ -1839,10 +1839,10 @@ static int power_pmu_event_init(struct perf_event
*event)
err = power_check_constraints(cpuhw, events, cflags, n + 1);
if (has_branch_stack(event)) {
- cpuhw-bhrb_filter = ppmu-bhrb_filter_map(
+ cpuhw-bhrb_hw_filter = ppmu-bhrb_filter_map(
event-attr.branch_sample_type);
- if (cpuhw-bhrb_filter == -1) {
+ if (cpuhw-bhrb_hw_filter == -1) {
put_cpu_var(cpu_hw_events);
return -EOPNOTSUPP;
}
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v7] powerpc/powernv: Poweroff (EPOW, DPO) events support for PowerNV platform
This patch adds support for FSP (Flexible Service Processor) EPOW (Early Power Off Warning) and DPO (Delayed Power Off) events for the PowerNV platform. EPOW events are generated by FSP due to various critical system conditions that require system shutdown. A few examples of these conditions are high ambient temperature or system running on UPS power with low UPS battery. DPO event is generated in response to admin initiated system shutdown request. Upon receipt of EPOW and DPO events the host kernel invokes orderly_poweroff() for performing graceful system shutdown. Reviewed-by: Joel Stanley j...@jms.id.au Reviewed-by: Vaibhav Jain vaib...@linux.vnet.ibm.com Reviewed-by: Michael Ellerman m...@ellerman.id.au Changes in v7: - Fixed logic to check epow support to avoid EPOW, DPO handling path on BMC. Changes in v6: - Made below changes as suggested by Michael Ellerman on previous patch. - Changed EPOW, DPO notifier blocks to use opal_power_control_event() and enhanced opal_power_control_event() to handle EPOW and DPO events. - Reorganized code and added/changed few variable, function names removing older ones. - Minor cleanup like removing unused headers, blank lines etc. Changes in v5: - Made changes to address review comments on previous patch. Changes in v4: - Made changes to address review comments on previous patch. Changes in v3: - Made changes to immediately call orderly_poweroff upon receipt of OPAL EPOW, DPO notifications. - Made code changes to address review comments on previous patch. - Made code changes to use existing OPAL EPOW API. - Removed patch to extract EPOW event timeout from OPAL device-tree. Changes in v2: - Made code changes to improve code as per previous review comments. - Added patch to obtain EPOW event timeout values from OPAL device-tree. Vipin K Parashar (1): powerpc/powernv: Add poweroff (EPOW, DPO) events support for PowerNV platform arch/powerpc/include/asm/opal-api.h| 40 arch/powerpc/include/asm/opal.h| 3 +- arch/powerpc/platforms/powernv/opal-power.c| 126 + arch/powerpc/platforms/powernv/opal-wrappers.S | 1 + 4 files changed, 152 insertions(+), 18 deletions(-) -- 1.9.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] ppc64 ftrace implementation
Why are your patches all as replies? On Wed, 3 Jun 2015 15:08:29 +0200 Torsten Duwe d...@lst.de wrote: Implement ftrace on ppc64 What do you mean Implement ftrace on ppc64? It's already implemented. I'm not even going to bother looking at this patch because I have no idea what its purpose is. -- Steve Signed-off-by: Torsten Duwe d...@suse.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[lockdep] cpufreq/ppc: possible circular locking dependency detected
Hi,
I see the following lockdep splat on my RackMac machine on boot:
[6.002593] Registering G5 CPU frequency driver
[6.011288] Frequency method: i2c/pfunc, Voltage method: i2c/pfunc
[6.023605] Low: 1800 Mhz, High: 2300 Mhz, Cur: 1800 MHz
[6.038022] ==
[6.042080] windfarm: CPUs control loops started.
[6.042084] wf_rm31: Backside control loop started.
[6.042086] wf_rm31: Slots control loop started.
[6.078644] [ INFO: possible circular locking dependency detected ]
[6.091149] 4.1.0-rc6-01265-g908e80d-dirty #15 Not tainted
[6.102083] ---
[6.114586] swapper/0/1 is trying to acquire lock:
[6.124136] (bus-mutex){+.+.+.}, at: [c004d450]
.pmac_i2c_open+0x30/0x100
[6.139933]
but task is already holding lock:
[6.151569] (policy-rwsem){+.+.+.}, at: [c0620bbc]
.__cpufreq_add_dev.isra.29+0x34c/0xad0
[6.170143]
which lock already depends on the new lock.
[6.186464]
the existing dependency chain (in reverse order) is:
[6.201401]
- #4 (policy-rwsem){+.+.+.}:
[6.210077][c00d6380] .lock_acquire+0x80/0x100
[6.222061][c07a411c] .down_write+0x6c/0x110
[6.233690][c0620bbc]
.__cpufreq_add_dev.isra.29+0x34c/0xad0
[6.248104][c0489dd8] .subsys_interface_register+0xc8/0x120
[6.262336][c06215f8] .cpufreq_register_driver+0x138/0x310
[6.276404][c0adeca8] .g5_cpufreq_init+0x9cc/0xa28
[6.289079][c000a714] .do_one_initcall+0xd4/0x270
[6.301577][c0aaa778] .kernel_init_freeable+0x190/0x270
[6.315120][c000b17c] .kernel_init+0x1c/0x120
[6.326928][c00095b4] .ret_from_kernel_thread+0x58/0xa4
[6.340467]
- #3 (subsys mutex#2){+.+.+.}:
[6.349149][c00d6380] .lock_acquire+0x80/0x100
[6.361130][c07a0ccc] .mutex_lock_nested+0xac/0x5a0
[6.373980][c048aff4] .bus_probe_device+0x44/0xf0
[6.386477][c0488318] .device_add+0x508/0x730
[6.398284][c048fb8c] .register_cpu+0xfc/0x150
[6.410266][c0aaf27c] .topology_init+0x108/0x1c0
[6.422595][c000a714] .do_one_initcall+0xd4/0x270
[6.435092][c0aaa778] .kernel_init_freeable+0x190/0x270
[6.448637][c000b17c] .kernel_init+0x1c/0x120
[6.460444][c00095b4] .ret_from_kernel_thread+0x58/0xa4
[6.473983]
- #2 (cpu_add_remove_lock){+.+.+.}:
[6.483536][c00d6380] .lock_acquire+0x80/0x100
[6.495517][c07a0ccc] .mutex_lock_nested+0xac/0x5a0
[6.508361][c00781ac] .cpu_maps_update_begin+0x1c/0x30
[6.521732][c0070220] .register_power_pmu+0xa0/0x128
[6.534752][c0abed50] .init_ppc970_pmu+0x6c/0x8c
[6.547081][c000a714] .do_one_initcall+0xd4/0x270
[6.559578][c0aaa698] .kernel_init_freeable+0xb0/0x270
[6.572950][c000b17c] .kernel_init+0x1c/0x120
[6.584758][c00095b4] .ret_from_kernel_thread+0x58/0xa4
[6.598297]
- #1 (host-mutex){+.+.+.}:
[6.606633][c00d6380] .lock_acquire+0x80/0x100
[6.618615][c07a0ccc] .mutex_lock_nested+0xac/0x5a0
[6.631458][c004d408] .kw_i2c_open+0x18/0x30
[6.643092][c004d4b4] .pmac_i2c_open+0x94/0x100
[6.655247][c0abb174] .smp_core99_probe+0x260/0x410
[6.668097][c0ab2f94] .smp_prepare_cpus+0x1ec/0x220
[6.680941][c0aaa670] .kernel_init_freeable+0x88/0x270
[6.694313][c000b17c] .kernel_init+0x1c/0x120
[6.706121][c00095b4] .ret_from_kernel_thread+0x58/0xa4
[6.719660]
- #0 (bus-mutex){+.+.+.}:
[6.727822][c00d5304] .__lock_acquire+0x1194/0x1b70
[6.740672][c00d6380] .lock_acquire+0x80/0x100
[6.752647][c07a0ccc] .mutex_lock_nested+0xac/0x5a0
[6.765497][c004d450] .pmac_i2c_open+0x30/0x100
[6.777652][c004da34] .pmac_i2c_do_begin+0x34/0x120
[6.790501][c00517e0] .pmf_call_one+0x50/0xd0
[6.802302][c06265ec] .g5_pfunc_switch_volt+0x2c/0xc0
[6.815501][c062659c] .g5_pfunc_switch_freq+0x1cc/0x1f0
[6.829040][c06262fc] .g5_cpufreq_target+0x2c/0x40
[6.841716][c061de40] .__cpufreq_driver_target+0x230/0x400
[6.855783][c0622bec]
.cpufreq_governor_performance+0x3c/0x60
[6.870364][c061f0d0] .__cpufreq_governor+0xc0/0x390
[6.883389][c061f9fc] .cpufreq_set_policy+0x25c/0x2c0
[6.896581][c06206d4]
[PATCH v7] powerpc/powernv: Add poweroff (EPOW, DPO) events support for PowerNV platform
This patch adds support for FSP (Flexible Service Processor)
EPOW (Early Power Off Warning) and DPO (Delayed Power Off) events for
the PowerNV platform. EPOW events are generated by FSP due to various
critical system conditions that require system shutdown. A few examples
of these conditions are high ambient temperature or system running on
UPS power with low UPS battery. DPO event is generated in response to
admin initiated system shutdown request. Upon receipt of EPOW and DPO
events the host kernel invokes orderly_poweroff() for performing
graceful system shutdown.
Reviewed-by: Joel Stanley j...@jms.id.au
Reviewed-by: Vaibhav Jain vaib...@linux.vnet.ibm.com
Reviewed-by: Michael Ellerman m...@ellerman.id.au
Signed-off-by: Vipin K Parashar vi...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal-api.h| 40
arch/powerpc/include/asm/opal.h| 3 +-
arch/powerpc/platforms/powernv/opal-power.c| 126 +
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
4 files changed, 152 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index 0321a90..f460435 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -730,6 +730,46 @@ struct opal_i2c_request {
__be64 buffer_ra; /* Buffer real address */
};
+/*
+ * EPOW status sharing (OPAL and the host)
+ *
+ * The host will pass on OPAL, a buffer of length OPAL_SYSEPOW_MAX
+ * with individual elements being 16 bits wide to fetch the system
+ * wide EPOW status. Each element in the buffer will contain the
+ * EPOW status in it's bit representation for a particular EPOW sub
+ * class as defiend here. So multiple detailed EPOW status bits
+ * specific for any sub class can be represented in a single buffer
+ * element as it's bit representation.
+ */
+
+/* System EPOW type */
+enum OpalSysEpow {
+ OPAL_SYSEPOW_POWER = 0,/* Power EPOW */
+ OPAL_SYSEPOW_TEMP = 1,/* Temperature EPOW */
+ OPAL_SYSEPOW_COOLING= 2,/* Cooling EPOW */
+ OPAL_SYSEPOW_MAX= 3,/* Max EPOW categories */
+};
+
+/* Power EPOW */
+enum OpalSysPower {
+ OPAL_SYSPOWER_UPS = 0x0001, /* System on UPS power */
+ OPAL_SYSPOWER_CHNG = 0x0002, /* System power config change */
+ OPAL_SYSPOWER_FAIL = 0x0004, /* System impending power failure */
+ OPAL_SYSPOWER_INCL = 0x0008, /* System incomplete power */
+};
+
+/* Temperature EPOW */
+enum OpalSysTemp {
+ OPAL_SYSTEMP_AMB= 0x0001, /* System over ambient temperature */
+ OPAL_SYSTEMP_INT= 0x0002, /* System over internal temperature */
+ OPAL_SYSTEMP_HMD= 0x0004, /* System over ambient humidity */
+};
+
+/* Cooling EPOW */
+enum OpalSysCooling {
+ OPAL_SYSCOOL_INSF = 0x0001, /* System insufficient cooling */
+};
+
#endif /* __ASSEMBLY__ */
#endif /* __OPAL_API_H */
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 042af1a..8b174f3 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -141,7 +141,8 @@ int64_t opal_pci_fence_phb(uint64_t phb_id);
int64_t opal_pci_reinit(uint64_t phb_id, uint64_t reinit_scope, uint64_t data);
int64_t opal_pci_mask_pe_error(uint64_t phb_id, uint16_t pe_number, uint8_t
error_type, uint8_t mask_action);
int64_t opal_set_slot_led_status(uint64_t phb_id, uint64_t slot_id, uint8_t
led_type, uint8_t led_action);
-int64_t opal_get_epow_status(__be64 *status);
+int64_t opal_get_epow_status(__be16 *epow_status, __be16 *num_epow_classes);
+int64_t opal_get_dpo_status(__be64 *dpo_timeout);
int64_t opal_set_system_attention_led(uint8_t led_action);
int64_t opal_pci_next_error(uint64_t phb_id, __be64 *first_frozen_pe,
__be16 *pci_error_type, __be16 *severity);
diff --git a/arch/powerpc/platforms/powernv/opal-power.c
b/arch/powerpc/platforms/powernv/opal-power.c
index ac46c2c..a27d390 100644
--- a/arch/powerpc/platforms/powernv/opal-power.c
+++ b/arch/powerpc/platforms/powernv/opal-power.c
@@ -9,9 +9,12 @@
* 2 of the License, or (at your option) any later version.
*/
+#define pr_fmt(fmt)opal-power: fmt
+
#include linux/kernel.h
#include linux/reboot.h
#include linux/notifier.h
+#include linux/of.h
#include asm/opal.h
#include asm/machdep.h
@@ -19,30 +22,95 @@
#define SOFT_OFF 0x00
#define SOFT_REBOOT 0x01
+/* Detect existing EPOW, DPO events */
+static bool poweroff_pending(void)
+{
+ int i, rc;
+ __be16 epow_classes;
+ __be16 opal_epow_status[OPAL_SYSEPOW_MAX] = {0};
+ __be64 opal_dpo_timeout;
+
+ /* Check for DPO event */
+ rc = opal_get_dpo_status(opal_dpo_timeout);
+ if (rc == OPAL_SUCCESS) {
+ pr_info(Existing DPO event detected.\n);
+ return true;
+ }
+
+ /*
+ * Check for
Re: [lockdep] cpufreq/ppc: possible circular locking dependency detected
On 08-06-15, 18:45, Denis Kirjanov wrote: Hi, I see the following lockdep splat on my RackMac machine on boot: What kernel version is it ? -- viresh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V8 00/28] Add new powerpc specific ELF core notes
Anshuman Khandual khand...@linux.vnet.ibm.com wrote on 19.05.2015 17:07:56: This patch series adds twelve new ELF core note sections which can be used with existing ptrace request PTRACE_GETREGSET-SETREGSET for accessing various transactional memory and other miscellaneous debug register sets on powerpc platform. Previous versions: == RFC: https://lkml.org/lkml/2014/4/1/292 V1: https://lkml.org/lkml/2014/4/2/43 V2: https://lkml.org/lkml/2014/5/5/88 V3: https://lkml.org/lkml/2014/5/23/486 V4: https://lkml.org/lkml/2014/11/11/6 V5: https://lkml.org/lkml/2014/11/25/134 V6: https://lkml.org/lkml/2014/12/2/98 V7: https://lkml.org/lkml/2015/1/14/19 Changes in V8: -- - Split the misc register set into individual ELF core notes - Implemented support for VSX register set (on and off TM) - Implemented support for EBB register set - Implemented review comments on previous versions - Some code re-arrangements, re-writes and documentation - Added comprehensive list of test cases into selftests This addresses all the issues I raised in my comments on V7. The register set layout looks good to me now. Thanks, Ulrich ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [lockdep] cpufreq/ppc: possible circular locking dependency detected
On 6/8/15, Viresh Kumar viresh.ku...@linaro.org wrote: On 08-06-15, 18:45, Denis Kirjanov wrote: Hi, I see the following lockdep splat on my RackMac machine on boot: What kernel version is it ? [6.091149] 4.1.0-rc6-01265-g908e80d-dirty #15 Not tainted -- viresh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [lockdep] cpufreq/ppc: possible circular locking dependency detected
On 08-06-15, 19:37, Denis Kirjanov wrote: [6.091149] 4.1.0-rc6-01265-g908e80d-dirty #15 Not tainted Sorry, this points to a dirty tree. Can you please explain what's more than rc6 is here ? Are you using any other patches from somewhere? -- viresh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [lockdep] cpufreq/ppc: possible circular locking dependency detected
On 6/8/15, Viresh Kumar viresh.ku...@linaro.org wrote: On 08-06-15, 19:37, Denis Kirjanov wrote: [6.091149] 4.1.0-rc6-01265-g908e80d-dirty #15 Not tainted Sorry, this points to a dirty tree. Can you please explain what's more than rc6 is here ? Are you using any other patches from somewhere? Ah, forgot to mention: I'm trying to fix the issue with the kmemleak so I've added debuginfo to the drivers/char/agp/uninorth-agp.c. Nothing special. -- viresh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] ppc64 ftrace implementation
On Mon, Jun 08, 2015 at 11:30:32AM -0400, Steven Rostedt wrote: Why are your patches all as replies? Because I cared too much about the threading and the series that the Re: escaped me. Implement ftrace on ppc64 What do you mean Implement ftrace on ppc64? It's already implemented. Sorry, too deep in the details. It's DYNAMIC_FTRACE_WITH_REGS, actually. Using gcc's -mprofile-kernel to call into ftrace... I'm not even going to bother looking at this patch because I have no idea what its purpose is. Understandable ;-) So: Implement DYNAMIC_FTRACE_WITH_REGS, in order to prepare for live patching. Other obvious things I forgot to mention? Torsten ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
