Re: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.

2013-11-06 Thread Shawn Guo
On Wed, Nov 06, 2013 at 03:53:24AM +, Li Xiubo wrote:
   If there are any comments that say PPC but are not PPC-specific, that
   should be fixed.
   Yes, find it.
  
   The comments is in sound/soc/fsl/Makefile :
   +++
   # Freescale PowerPC SSI/DMA Platform Support
   ---
  
   But fsl-spdif.o is also under it.
   And this is also support ARM and PowerPC platforms at the same time ?
   If so, the comments should be modified to :
   +++
   # Freescale PowerPC and ARM SSI/DMA Platform Support
   ---
  
  Yes, this should be changed.
  
 
 How about :
 +
 # Freescale PowerPC and ARM SSI/DMA/SAI/SPDIF Platform Support  
 -
  ?

Or we can just drop 'PowerPC and ARM'?

Shawn

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: [PATCHv2 5/8] ASoC: SGTL5000: Enhance the SGTL5000 codec driver about regulator.

2013-11-06 Thread Li Xiubo
  On VF610 series there are no regulators used, and now whether the
  CONFIG_REGULATOR mirco is enabled or not, for the VF610 audio patch
  series, the board cannot be probe successfully.
  And this patch will solve this issue.
 
 I don't understand what this is for at all, you're just saying there is a
 problem you're trying to solve but you don't explain anything about what
 the problem is or how your changes address it.
 

Sorry for confusing.

The SGTL5000 is based on regulators and when it is disabled, there will be an 
error returns directly while the SGTL5000 codec is probing.
But on VF610 boards there has no regulators or needn't configure them, so the 
CONFIG_REGULATOR is disabled, and then the error is returned causing
to the SGTL5000 probe broken. 

Has I make it clear?

  +#ifndef CONFIG_SND_SOC_FSL_SGTL5000_VF610
   static int ldo_regulator_register(struct snd_soc_codec *codec,
 
 This is definitely broken, it won't work with multi-platform kernels, and
 I don't understand what this is supposed to do - what is the reason for
 making this change?


Yes, it is.

How about adding one node properties like : regulator-exist, which will be 
controlled by platform data ?





___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.

2013-11-06 Thread Li Xiubo
If there are any comments that say PPC but are not PPC-specific,
 that
should be fixed.
Yes, find it.
   
The comments is in sound/soc/fsl/Makefile :
+++
# Freescale PowerPC SSI/DMA Platform Support
---
   
But fsl-spdif.o is also under it.
And this is also support ARM and PowerPC platforms at the same
 time ?
If so, the comments should be modified to :
+++
# Freescale PowerPC and ARM SSI/DMA Platform Support
---
  
   Yes, this should be changed.
  
 
  How about :
  +
  # Freescale PowerPC and ARM SSI/DMA/SAI/SPDIF Platform Support
  -
   ?
 
 Or we can just drop 'PowerPC and ARM'?
 

Yes, this will be better.


Best Regards,
Xiubo




___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH V6 1/2] powerpc/85xx: Add QE common init function

2013-11-06 Thread Xie Xiaobo
Define a QE init function in common file, and avoid
the same codes being duplicated in board files.

Signed-off-by: Xie Xiaobo x@freescale.com
---
V6 - V5: add of_device_is_available check.
V5 - V4: add the board files modification, remove the qe_pic_init.
V4 - V3: Nochange

 arch/powerpc/platforms/85xx/common.c  | 38 +++
 arch/powerpc/platforms/85xx/mpc85xx.h |  6 +
 arch/powerpc/platforms/85xx/mpc85xx_mds.c | 29 ++-
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 25 ++--
 4 files changed, 48 insertions(+), 50 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/common.c 
b/arch/powerpc/platforms/85xx/common.c
index d0861a0..970576b 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -7,6 +7,7 @@
  */
 #include linux/of_platform.h
 
+#include asm/qe.h
 #include sysdev/cpm2_pic.h
 
 #include mpc85xx.h
@@ -80,3 +81,40 @@ void __init mpc85xx_cpm2_pic_init(void)
irq_set_chained_handler(irq, cpm2_cascade);
 }
 #endif
+
+#ifdef CONFIG_QUICC_ENGINE
+void __init mpc85xx_qe_init(void)
+{
+   struct device_node *np;
+
+   np = of_find_compatible_node(NULL, NULL, fsl,qe);
+   if (!np) {
+   np = of_find_node_by_name(NULL, qe);
+   if (!np) {
+   pr_err(%s: Could not find Quicc Engine node\n,
+   __func__);
+   return;
+   }
+   }
+
+   if (!of_device_is_available(np)) {
+   of_node_put(np);
+   return;
+   }
+
+   qe_reset();
+   of_node_put(np);
+
+   np = of_find_node_by_name(NULL, par_io);
+   if (np) {
+   struct device_node *ucc;
+
+   par_io_init(np);
+   of_node_put(np);
+
+   for_each_node_by_name(ucc, ucc)
+   par_io_of_config(ucc);
+
+   }
+}
+#endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx.h 
b/arch/powerpc/platforms/85xx/mpc85xx.h
index 2aa7c5d..fc51dd4 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx.h
+++ b/arch/powerpc/platforms/85xx/mpc85xx.h
@@ -8,4 +8,10 @@ extern void mpc85xx_cpm2_pic_init(void);
 static inline void __init mpc85xx_cpm2_pic_init(void) {}
 #endif /* CONFIG_CPM2 */
 
+#ifdef CONFIG_QUICC_ENGINE
+extern void mpc85xx_qe_init(void);
+#else
+static inline void __init mpc85xx_qe_init(void) {}
+#endif
+
 #endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c 
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index a7b3621..34f3c5e 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2006-2010, 2012 Freescale Semiconductor, Inc.
+ * Copyright (C) 2006-2010, 2012-2013 Freescale Semiconductor, Inc.
  * All rights reserved.
  *
  * Author: Andy Fleming aflem...@freescale.com
@@ -238,32 +238,7 @@ static void __init mpc85xx_mds_qe_init(void)
 {
struct device_node *np;
 
-   np = of_find_compatible_node(NULL, NULL, fsl,qe);
-   if (!np) {
-   np = of_find_node_by_name(NULL, qe);
-   if (!np)
-   return;
-   }
-
-   if (!of_device_is_available(np)) {
-   of_node_put(np);
-   return;
-   }
-
-   qe_reset();
-   of_node_put(np);
-
-   np = of_find_node_by_name(NULL, par_io);
-   if (np) {
-   struct device_node *ucc;
-
-   par_io_init(np);
-   of_node_put(np);
-
-   for_each_node_by_name(ucc, ucc)
-   par_io_of_config(ucc);
-   }
-
+   mpc85xx_qe_init();
mpc85xx_mds_reset_ucc_phys();
 
if (machine_is(p1021_mds)) {
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c 
b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 53b6fb0..e15bdd1 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -1,7 +1,7 @@
 /*
  * MPC85xx RDB Board Setup
  *
- * Copyright 2009,2012 Freescale Semiconductor Inc.
+ * Copyright 2009,2012-2013 Freescale Semiconductor Inc.
  *
  * 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
@@ -98,26 +98,7 @@ static void __init mpc85xx_rdb_setup_arch(void)
fsl_pci_assign_primary();
 
 #ifdef CONFIG_QUICC_ENGINE
-   np = of_find_compatible_node(NULL, NULL, fsl,qe);
-   if (!np) {
-   pr_err(%s: Could not find Quicc Engine node\n, __func__);
-   goto qe_fail;
-   }
-
-   qe_reset();
-   of_node_put(np);
-
-   np = of_find_node_by_name(NULL, par_io);
-   if (np) {
-   struct device_node *ucc;
-
-   par_io_init(np);
-   of_node_put(np);
-
-   for_each_node_by_name(ucc, ucc)
-   par_io_of_config(ucc);
-
-   }
+   mpc85xx_qe_init();
 #if 

[PATCH V6 2/2] powerpc/85xx: Add TWR-P1025 board support

2013-11-06 Thread Xie Xiaobo
TWR-P1025 Overview
 -
 512Mbyte DDR3 (on board DDR)
 64MB Nor Flash
 eTSEC1: Connected to RGMII PHY AR8035
 eTSEC3: Connected to RGMII PHY AR8035
 Two USB2.0 Type A
 One microSD Card slot
 One mini-PCIe slot
 One mini-USB TypeB dual UART

Signed-off-by: Michael Johnston michael.johns...@freescale.com
Signed-off-by: Xie Xiaobo x@freescale.com
---
Patch V6: Add a binding doc for ssd1289 device.
Patch V5: Miscellaneous modification. e.g. move the qe ucc node into dtsi.
Patch V4: Fix the mdio phy interrupt issue in dts
Patch V3: fix pcie range issue in dts
Patch V2: QE related init codes were factored out to a common file

 .../devicetree/bindings/video/ssd1289fb.txt|  13 +
 arch/powerpc/boot/dts/p1025twr.dts |  95 +++
 arch/powerpc/boot/dts/p1025twr.dtsi| 280 +
 arch/powerpc/platforms/85xx/Kconfig|   6 +
 arch/powerpc/platforms/85xx/Makefile   |   1 +
 arch/powerpc/platforms/85xx/twr_p102x.c| 147 +++
 6 files changed, 542 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/ssd1289fb.txt
 create mode 100644 arch/powerpc/boot/dts/p1025twr.dts
 create mode 100644 arch/powerpc/boot/dts/p1025twr.dtsi
 create mode 100644 arch/powerpc/platforms/85xx/twr_p102x.c

diff --git a/Documentation/devicetree/bindings/video/ssd1289fb.txt 
b/Documentation/devicetree/bindings/video/ssd1289fb.txt
new file mode 100644
index 000..4fcd5e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ssd1289fb.txt
@@ -0,0 +1,13 @@
+* Solomon SSD1289 Framebuffer Driver
+
+Required properties:
+  - compatible: Should be solomon,ssd1289fb. The only supported bus for
+now is lbc.
+  - reg: Should contain address of the controller on the LBC bus. The detail
+was described in Documentation/devicetree/bindings/powerpc/fsl/lbc.txt
+
+Examples:
+display@2,0 {
+   compatible = solomon,ssd1289fb;
+   reg = 0x2 0x 0x0004;
+};
diff --git a/arch/powerpc/boot/dts/p1025twr.dts 
b/arch/powerpc/boot/dts/p1025twr.dts
new file mode 100644
index 000..9036a49
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1025twr.dts
@@ -0,0 +1,95 @@
+/*
+ * P1025 TWR Device Tree Source (32-bit address map)
+ *
+ * Copyright 2013 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.
+ */
+
+/include/ fsl/p1021si-pre.dtsi
+/ {
+   model = fsl,P1025;
+   compatible = fsl,TWR-P1025;
+
+   memory {
+   device_type = memory;
+   };
+
+   lbc: localbus@ffe05000 {
+   reg = 0 0xffe05000 0 0x1000;
+
+   /* NOR Flash and SSD1289 */
+   ranges = 0x0 0x0 0x0 0xec00 0x0400
+ 0x2 0x0 0x0 0xe000 0x0002;
+   };
+
+   soc: soc@ffe0 {
+   ranges = 0x0 0x0 0xffe0 0x10;
+   };
+
+   pci0: pcie@ffe09000 {
+   ranges = 0x200 0x0 0xa000 0 0xa000 0x0 0x2000
+ 0x100 0x0 0x 0 0xffc1 0x0 0x1;
+   reg = 0 0xffe09000 0 0x1000;
+   pcie@0 {
+   ranges = 0x200 0x0 0xa000
+ 0x200 0x0 0xa000
+   

Re: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.

2013-11-06 Thread Mark Brown
On Tue, Nov 05, 2013 at 03:21:49AM +, Li Xiubo wrote:

 As your opinions, should I move the four register writing operations to 
 .set_sysclk/set_clkdiv/... functions too ?
 Or just add a clk_disable_unprepare() after them here, and then add 
 clk_prepare_enable in one of .set_sysclk/set_clkdiv/...?

The latter.


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv2 5/8] ASoC: SGTL5000: Enhance the SGTL5000 codec driver about regulator.

2013-11-06 Thread Mark Brown
On Wed, Nov 06, 2013 at 08:59:53AM +, Li Xiubo wrote:

Please fix your mailer to word wrap within paragraphs.

 The SGTL5000 is based on regulators and when it is disabled, there
 will be an error returns directly while the SGTL5000 codec is probing.

What makes you say this?  That's not how the regulator API works.  Have
you actually seen any problems?


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: memcpy optimization for 64bit LE

2013-11-06 Thread Philippe Bergheaud

Michael Neuling wrote:

Philippe Bergheaud fe...@linux.vnet.ibm.com wrote:



Unaligned stores take alignment exceptions on POWER7 running in little-endian.
This is a dumb little-endian base memcpy that prevents unaligned stores.
It is replaced by the VMX memcpy at boot.



Is this any faster than the generic version?


The little-endian assembly code of the base memcpy is similar to the code 
emitted by gcc when compiling the generic memcpy in lib/string.c, and runs at 
the same speed.
However, a little-endian assembly version of the base memcpy is required (as 
opposed to a C version), in order to use the self-modifying code 
instrumentation system.
After the cpu feature CPU_FTR_ALTIVEC is detected at boot, the slow base memcpy 
is nop'ed out, and the fast memcpy_power7 is used instead.

Philippe

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-06 Thread Will Deacon
On Tue, Nov 05, 2013 at 06:49:43PM +, Peter Zijlstra wrote:
 On Tue, Nov 05, 2013 at 02:05:48PM +, Will Deacon wrote:
+
+#define smp_store_release(p, v)
  \
+do { \
+ smp_mb();   \
+ ACCESS_ONCE(p) = (v);   \
+} while (0)
+
+#define smp_load_acquire(p, v) 
  \
+do { \
+ typeof(p) ___p1 = ACCESS_ONCE(p);   \
+ smp_mb();   \
+ return ___p1;   \
+} while (0)
  
  What data sizes do these accessors operate on? Assuming that we want
  single-copy atomicity (with respect to interrupts in the UP case), we
  probably want a check to stop people passing in things like structs.
 
 Fair enough; I think we should restrict to native word sizes same as we
 do for atomics.
 
 Something like so perhaps:
 
 #ifdef CONFIG_64BIT
 #define __check_native_word(t)(sizeof(t) == 4 || sizeof(t) == 8)

Ok, if we want to support 32-bit accesses on 64-bit machines, that will
complicate some of your assembly (more below).

 #else
 #define __check_native_word(t)(sizeof(t) == 4)
 #endif
 
 #define smp_store_release(p, v)   \
 do {  \
   BUILD_BUG_ON(!__check_native_word(p));  \
   smp_mb();   \
   ACCESS_ONCE(p) = (v);   \
 } while (0)
 
+#define smp_store_release(p, v)
  \
+do { \
+ asm volatile (stlr %w0 [%1] : : r (v), r (p) : memory);\
  
  Missing comma between the operands. Also, that 'w' output modifier enforces
  a 32-bit store (same early question about sizes). Finally, it might be more
  efficient to use =Q for the addressing mode, rather than take the address
  of p manually.
 
 so something like:
 
   asm volatile (stlr %0, [%1] : : r (v), =Q (p) : memory);
 
 ?
 
 My inline asm foo is horrid and I mostly get by with copy paste from a
 semi similar existing form :/

Almost: you just need to drop the square brackets and make the memory
location an output operand:

asm volatile(stlr %1, %0 : =Q (p) : r (v) : memory);

however, for a 32-bit access, you need to use an output modifier:

asm volatile(stlr %w1, %0 : =Q (p) : r (v) : memory);

so I guess a switch on sizeof(p) is required.

  Random other question: have you considered how these accessors should behave
  when presented with __iomem pointers?
 
 A what? ;-)

Then let's go with Paul's suggestion of mandating __kernel, or the like
(unless we need to worry about __user addresses for things like futexes?).

Will
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 2/3] powerpc/kvm: fix rare but potential deadlock scene

2013-11-06 Thread Paul Mackerras
On Wed, Nov 06, 2013 at 02:02:07PM +0800, Liu ping fan wrote:
 On Wed, Nov 6, 2013 at 1:04 PM, Paul Mackerras pau...@samba.org wrote:
  On Tue, Nov 05, 2013 at 03:42:43PM +0800, Liu Ping Fan wrote:
  Since kvmppc_hv_find_lock_hpte() is called from both virtmode and
  realmode, so it can trigger the deadlock.
 
  Good catch, we should have preemption disabled while ever we have a
  HPTE locked.
 
  @@ -474,8 +474,10 @@ static int kvmppc_mmu_book3s_64_hv_xlate(struct 
  kvm_vcpu *vcpu, gva_t eaddr,
}
 
/* Find the HPTE in the hash table */
  + preempt_disable();
index = kvmppc_hv_find_lock_hpte(kvm, eaddr, slb_v,
 HPTE_V_VALID | HPTE_V_ABSENT);
  + preempt_enable();
 
  Which means we need to add the preempt_enable after unlocking the
  HPTE, not here.
 
 Yes. Sorry, but I am not sure about whether we can call
 preempt_disable/enable() in realmode. I think since thread_info is
 allocated with linear address, so we can use preempt_disable/enable()
 inside kvmppc_hv_find_lock_hpte(), right?

Your analysis correctly pointed out that we can get a deadlock if we
can be preempted while holding a lock on a HPTE.  That means that we
have to disable preemption before taking an HPTE lock and keep it
disabled until after we unlock the HPTE.  Since the point of
kvmppc_hv_find_lock_hpte() is to lock the HPTE and return with it
locked, we can't have the preempt_enable() inside it.  The
preempt_enable() has to come after we have unlocked the HPTE.  That is
also why we can't have the preempt_enable() where your patch put it;
it needs to be about 9 lines further down, after the statement
hptep[0] = v.  (We also need to make sure to re-enable preemption in
the index  0 case.)

Regards,
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 3/3] powerpc/kvm: remove redundant assignment

2013-11-06 Thread Alexander Graf

On 05.11.2013, at 08:42, Liu Ping Fan kernelf...@gmail.com wrote:

 Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com

Patch description missing.

Please add Paul's ack in the next revision of this patch :).


Alex

 ---
 arch/powerpc/kvm/book3s_64_mmu_hv.c | 1 -
 1 file changed, 1 deletion(-)
 
 diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
 b/arch/powerpc/kvm/book3s_64_mmu_hv.c
 index 28160ac..7682837 100644
 --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
 +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
 @@ -731,7 +731,6 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run, 
 struct kvm_vcpu *vcpu,
   lock_rmap(rmap);
 
   /* Check if we might have been invalidated; let the guest retry if so */
 - ret = RESUME_GUEST;
   if (mmu_notifier_retry(vcpu-kvm, mmu_seq)) {
   unlock_rmap(rmap);
   goto out_unlock;
 -- 
 1.8.1.4
 
 --
 To unsubscribe from this list: send the line unsubscribe kvm-ppc in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-06 Thread Peter Zijlstra

Subject: arch: Introduce smp_load_acquire(), smp_store_release()
From: Peter Zijlstra pet...@infradead.org
Date: Mon, 4 Nov 2013 20:18:11 +0100

A number of situations currently require the heavyweight smp_mb(),
even though there is no need to order prior stores against later
loads.  Many architectures have much cheaper ways to handle these
situations, but the Linux kernel currently has no portable way
to make use of them.

This commit therefore supplies smp_load_acquire() and
smp_store_release() to remedy this situation.  The new
smp_load_acquire() primitive orders the specified load against
any subsequent reads or writes, while the new smp_store_release()
primitive orders the specifed store against any prior reads or
writes.  These primitives allow array-based circular FIFOs to be
implemented without an smp_mb(), and also allow a theoretical
hole in rcu_assign_pointer() to be closed at no additional
expense on most architectures.

In addition, the RCU experience transitioning from explicit
smp_read_barrier_depends() and smp_wmb() to rcu_dereference()
and rcu_assign_pointer(), respectively resulted in substantial
improvements in readability.  It therefore seems likely that
replacing other explicit barriers with smp_load_acquire() and
smp_store_release() will provide similar benefits.  It appears
that roughly half of the explicit barriers in core kernel code
might be so replaced.

Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Mathieu Desnoyers mathieu.desnoy...@polymtl.ca
Cc: Michael Ellerman mich...@ellerman.id.au
Cc: Michael Neuling mi...@neuling.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Victor Kaplansky vict...@il.ibm.com
Cc: Oleg Nesterov o...@redhat.com
Cc: Anton Blanchard an...@samba.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Signed-off-by: Peter Zijlstra pet...@infradead.org
---
 Documentation/memory-barriers.txt |  157 +-
 arch/alpha/include/asm/barrier.h  |   15 +++
 arch/arc/include/asm/barrier.h|   15 +++
 arch/arm/include/asm/barrier.h|   15 +++
 arch/arm64/include/asm/barrier.h  |   50 ++
 arch/avr32/include/asm/barrier.h  |   14 +++
 arch/blackfin/include/asm/barrier.h   |   15 +++
 arch/cris/include/asm/barrier.h   |   15 +++
 arch/frv/include/asm/barrier.h|   15 +++
 arch/h8300/include/asm/barrier.h  |   15 +++
 arch/hexagon/include/asm/barrier.h|   15 +++
 arch/ia64/include/asm/barrier.h   |   49 ++
 arch/m32r/include/asm/barrier.h   |   15 +++
 arch/m68k/include/asm/barrier.h   |   15 +++
 arch/metag/include/asm/barrier.h  |   15 +++
 arch/microblaze/include/asm/barrier.h |   15 +++
 arch/mips/include/asm/barrier.h   |   15 +++
 arch/mn10300/include/asm/barrier.h|   15 +++
 arch/parisc/include/asm/barrier.h |   15 +++
 arch/powerpc/include/asm/barrier.h|   21 
 arch/s390/include/asm/barrier.h   |   15 +++
 arch/score/include/asm/barrier.h  |   15 +++
 arch/sh/include/asm/barrier.h |   15 +++
 arch/sparc/include/asm/barrier_32.h   |   15 +++
 arch/sparc/include/asm/barrier_64.h   |   15 +++
 arch/tile/include/asm/barrier.h   |   15 +++
 arch/unicore32/include/asm/barrier.h  |   15 +++
 arch/x86/include/asm/barrier.h|   15 +++
 arch/xtensa/include/asm/barrier.h |   15 +++
 include/linux/compiler.h  |9 +
 30 files changed, 581 insertions(+), 79 deletions(-)

--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -371,33 +371,35 @@ VARIETIES OF MEMORY BARRIER
 
 And a couple of implicit varieties:
 
- (5) LOCK operations.
+ (5) ACQUIRE operations.
 
  This acts as a one-way permeable barrier.  It guarantees that all memory
- operations after the LOCK operation will appear to happen after the LOCK
- operation with respect to the other components of the system.
+ operations after the ACQUIRE operation will appear to happen after the
+ ACQUIRE operation with respect to the other components of the system.
 
- Memory operations that occur before a LOCK operation may appear to happen
- after it completes.
+ Memory operations that occur before a ACQUIRE operation may appear to
+ happen after it completes.
 
- A LOCK operation should almost always be paired with an UNLOCK operation.
+ A ACQUIRE operation should almost always be paired with an RELEASE
+ operation.
 
 
- (6) UNLOCK operations.
+ (6) RELEASE operations.
 
  This also acts as a one-way permeable barrier.  It guarantees that all
- memory operations before the UNLOCK operation will appear to happen before
- the UNLOCK operation with respect to the other components of the system.
+ memory operations before the RELEASE operation will appear to happen
+ before the RELEASE operation with respect to the other components of the
+ system.
 
- Memory operations that occur after an UNLOCK 

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-06 Thread Geert Uytterhoeven
On Wed, Nov 6, 2013 at 1:39 PM, Peter Zijlstra pet...@infradead.org wrote:
  Documentation/memory-barriers.txt |  157 
 +-
  arch/alpha/include/asm/barrier.h  |   15 +++
  arch/arc/include/asm/barrier.h|   15 +++
  arch/arm/include/asm/barrier.h|   15 +++
  arch/arm64/include/asm/barrier.h  |   50 ++
  arch/avr32/include/asm/barrier.h  |   14 +++
  arch/blackfin/include/asm/barrier.h   |   15 +++
  arch/cris/include/asm/barrier.h   |   15 +++
  arch/frv/include/asm/barrier.h|   15 +++
  arch/h8300/include/asm/barrier.h  |   15 +++
  arch/hexagon/include/asm/barrier.h|   15 +++
  arch/ia64/include/asm/barrier.h   |   49 ++
  arch/m32r/include/asm/barrier.h   |   15 +++
  arch/m68k/include/asm/barrier.h   |   15 +++
  arch/metag/include/asm/barrier.h  |   15 +++
  arch/microblaze/include/asm/barrier.h |   15 +++
  arch/mips/include/asm/barrier.h   |   15 +++
  arch/mn10300/include/asm/barrier.h|   15 +++
  arch/parisc/include/asm/barrier.h |   15 +++
  arch/powerpc/include/asm/barrier.h|   21 
  arch/s390/include/asm/barrier.h   |   15 +++
  arch/score/include/asm/barrier.h  |   15 +++
  arch/sh/include/asm/barrier.h |   15 +++
  arch/sparc/include/asm/barrier_32.h   |   15 +++
  arch/sparc/include/asm/barrier_64.h   |   15 +++
  arch/tile/include/asm/barrier.h   |   15 +++
  arch/unicore32/include/asm/barrier.h  |   15 +++
  arch/x86/include/asm/barrier.h|   15 +++
  arch/xtensa/include/asm/barrier.h |   15 +++
  include/linux/compiler.h  |9 +
  30 files changed, 581 insertions(+), 79 deletions(-)

This is screaming for a default implementation in asm-generic.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-06 Thread Peter Zijlstra
On Wed, Nov 06, 2013 at 01:51:10PM +0100, Geert Uytterhoeven wrote:
 This is screaming for a default implementation in asm-generic.

Right you are... how about a little something like this?

There's a few archs I didn't fully merge with the generic one because of
weird nop implementations.

asm volatile (nop :: ) vs asm volatile (nop ::: memory) and the
like. They probably can (and should) use the regular asm volatile
(nop) but I misplaced the toolchains for many of the weird archs so I
didn't attempt.

Also fixed a silly mistake in the return type definition for most
smp_load_acquire() implementions: typeof(p) vs typeof(*p).

---
Subject: arch: Introduce smp_load_acquire(), smp_store_release()
From: Peter Zijlstra pet...@infradead.org
Date: Mon, 4 Nov 2013 20:18:11 +0100

A number of situations currently require the heavyweight smp_mb(),
even though there is no need to order prior stores against later
loads.  Many architectures have much cheaper ways to handle these
situations, but the Linux kernel currently has no portable way
to make use of them.

This commit therefore supplies smp_load_acquire() and
smp_store_release() to remedy this situation.  The new
smp_load_acquire() primitive orders the specified load against
any subsequent reads or writes, while the new smp_store_release()
primitive orders the specifed store against any prior reads or
writes.  These primitives allow array-based circular FIFOs to be
implemented without an smp_mb(), and also allow a theoretical
hole in rcu_assign_pointer() to be closed at no additional
expense on most architectures.

In addition, the RCU experience transitioning from explicit
smp_read_barrier_depends() and smp_wmb() to rcu_dereference()
and rcu_assign_pointer(), respectively resulted in substantial
improvements in readability.  It therefore seems likely that
replacing other explicit barriers with smp_load_acquire() and
smp_store_release() will provide similar benefits.  It appears
that roughly half of the explicit barriers in core kernel code
might be so replaced.


Cc: Michael Ellerman mich...@ellerman.id.au
Cc: Michael Neuling mi...@neuling.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Victor Kaplansky vict...@il.ibm.com
Cc: Oleg Nesterov o...@redhat.com
Cc: Anton Blanchard an...@samba.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Mathieu Desnoyers mathieu.desnoy...@polymtl.ca
Signed-off-by: Peter Zijlstra pet...@infradead.org
---
 Documentation/memory-barriers.txt |  157 +-
 arch/alpha/include/asm/barrier.h  |   25 +
 arch/arc/include/asm/Kbuild   |1 
 arch/arc/include/asm/atomic.h |5 +
 arch/arc/include/asm/barrier.h|   42 -
 arch/arm/include/asm/barrier.h|   15 +++
 arch/arm64/include/asm/barrier.h  |   50 ++
 arch/avr32/include/asm/barrier.h  |   17 +--
 arch/blackfin/include/asm/barrier.h   |   18 ---
 arch/cris/include/asm/Kbuild  |1 
 arch/cris/include/asm/barrier.h   |   25 -
 arch/frv/include/asm/barrier.h|8 -
 arch/h8300/include/asm/barrier.h  |   21 
 arch/hexagon/include/asm/Kbuild   |1 
 arch/hexagon/include/asm/barrier.h|   41 
 arch/ia64/include/asm/barrier.h   |   49 ++
 arch/m32r/include/asm/barrier.h   |   80 -
 arch/m68k/include/asm/barrier.h   |   14 ---
 arch/metag/include/asm/barrier.h  |   15 +++
 arch/microblaze/include/asm/Kbuild|1 
 arch/microblaze/include/asm/barrier.h |   27 -
 arch/mips/include/asm/barrier.h   |   15 +++
 arch/mn10300/include/asm/Kbuild   |1 
 arch/mn10300/include/asm/barrier.h|   37 
 arch/parisc/include/asm/Kbuild|1 
 arch/parisc/include/asm/barrier.h |   35 ---
 arch/powerpc/include/asm/barrier.h|   21 
 arch/s390/include/asm/barrier.h   |   15 +++
 arch/score/include/asm/Kbuild |1 
 arch/score/include/asm/barrier.h  |   16 ---
 arch/sh/include/asm/barrier.h |   21 
 arch/sparc/include/asm/barrier_32.h   |   11 --
 arch/sparc/include/asm/barrier_64.h   |   15 +++
 arch/tile/include/asm/barrier.h   |   68 --
 arch/unicore32/include/asm/barrier.h  |   11 --
 arch/x86/include/asm/barrier.h|   15 +++
 arch/xtensa/include/asm/barrier.h |9 -
 include/asm-generic/barrier.h |   55 +--
 include/linux/compiler.h  |9 +
 39 files changed, 375 insertions(+), 594 deletions(-)

--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -371,33 +371,35 @@ VARIETIES OF MEMORY BARRIER
 
 And a couple of implicit varieties:
 
- (5) LOCK operations.
+ (5) ACQUIRE operations.
 
  This acts as a one-way permeable barrier.  It guarantees that all memory
- operations after the LOCK operation will appear to happen after the LOCK
-  

Re: [RFC PATCH] ehci-platform: Merge ppc-of EHCI driver into the ehci-platform driver

2013-11-06 Thread Alan Stern
On Wed, 6 Nov 2013, Alistair Popple wrote:

 Currently the ppc-of driver uses the compatibility string
 usb-ehci. This means platforms that use device-tree and implement an
 EHCI compatible interface have to either use the ppc-of driver or add
 a compatible line to the ehci-platform driver. It would be more
 appropriate for the platform driver to be compatible with usb-ehci
 as non-powerpc platforms are also beginning to utilise device-tree.
 
 This patch merges the device tree property parsing from ehci-ppc-of
 into the platform driver and adds a usb-ehci compatibility
 string. The existing ehci-ppc-of driver is renamed to ehci-440epx as
 it contains platform specific work arounds for the 440EPX SoC.
 
 Signed-off-by: Alistair Popple alist...@popple.id.au
 ---
 
 So I could submit something like this that essentially merges the ppc-of 
 driver into the platform driver instead of adding the ibm,akebono-ehci 
 compatible line to the platform driver.
 
 However I'm still fairly new to device-tree so I'm not sure what (if any) the 
 broader impact would be. A quick grep for usb-ehci turned up a couple of 
 ARM 
 device tree's using it however they all provided their own drivers and don't 
 select CONFIG_USB_EHCI_HCD_PLATFORM so I'm guess they shouldn't be impacted.
 
 I have attempted to fix up any PowerPC device trees/configs, although I 
 wasn't 
 sure if usb-ehci should remain in sequoia.dts or not given that it needs to 
 use the 440EPX specific driver.
 
 Also this hasn't been tested (beyond compilation) yet.

 diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-
 platform.c
 index f6b790c..027f368 100644
 --- a/drivers/usb/host/ehci-platform.c
 +++ b/drivers/usb/host/ehci-platform.c
 @@ -77,6 +77,7 @@ static int ehci_platform_probe(struct platform_device *dev)
   struct usb_hcd *hcd;
   struct resource *res_mem;
   struct usb_ehci_pdata *pdata;
 + struct device_node *dn = dev-dev.of_node;
   int irq;
   int err = -ENOMEM;
  
 @@ -96,6 +97,18 @@ static int ehci_platform_probe(struct platform_device *dev)
  
   pdata = dev_get_platdata(dev-dev);
  
 + /* Initialise platform data from device tree if available. */
 + if (!dn) {

Shouldn't this be if (dn)?

 + if (of_get_property(dn, big-endian, NULL)) {
 + pdata-big_endian_mmio = 1;
 + pdata-big_endian_desc = 1;
 + }
 + if (of_get_property(dn, big-endian-regs, NULL))
 + pdata-big_endian_mmio = 1;
 + if (of_get_property(dn, big-endian-desc, NULL))
 + pdata-big_endian_desc = 1;
 + }
 +

This isn't good if there is more than one EHCI controller using 
ehci-platform.  To accomodate such cases, it would be necessary to 
allocate a separate copy of ehci_platform_defaults for each controller.

Alan Stern

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver

2013-11-06 Thread Ben Hutchings
On Wed, 2013-11-06 at 12:34 +1100, Alistair Popple wrote:
 On Tue, 5 Nov 2013 23:11:50 Ben Hutchings wrote:
  On Wed, 2013-11-06 at 06:54 +1100, Benjamin Herrenschmidt wrote:
 
 [snip]
 
   It's an SoC bit so there's little point making it generally
   selectable by the user.
  
  I think a better way to do this is:
  
  config IBM_EMAC_RGMII_WOL
  bool IBM EMAC RGMII wake-on-LAN support
  depends on MY_WONDERFUL_NEW_SOC || COMPILE_TEST
  default y if MY_WONDERFUL_NEW_SOC
  
  Then anyone making an API change that affects this driver can check that
  it still complies.
 
 The method used in this patch is the same as what is currently used by the 
 other IBM EMAC PHY interfaces (eg. config IBM_EMAC_ZMII etc). I'm happy to 
 send a patch to update all of those as well for consistency but that would 
 mean adding what each platform requires into EMACS Kconfig as well.
 
 Personally I think it is nicer to keep the definitions of what each platform 
 requires in one place (ie. arch/powerpc/platforms/44x/Kconfig) as it is 
 consistent with what we do for other 44x drivers, however I am happy to use 
 the above method if people think it's better.

Yes, I see your point.

 Alternatively we could do something like this:
 
 config IBM_EMAC_RGMII_WOL
 bool
 default y if COMPILE_TEST
 default n
 
 This would leave the platform dependencies as they are currently but still 
 allow compile testing.

It still shouldn't default to y in that case.  Instead you can make the
symbol conditionally configurable:

config IBM_EMAC_RGMII_WOL
bool IBM EMAC RGMII wake-on-LAN support if COMPILE_TEST

and then select this from your platform Kconfig as you intended.

(There is no need to put 'default n' as that's implicit for a
configurable symbol.  But it doesn't hurt either.)

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v3 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100

2013-11-06 Thread Alessio Igor Bogani
On lun, 2013-11-04 at 08:07 +1100, Stephen Chivers wrote: 
 Add support for the Motorola/Emerson MVME5100 Single Board Computer.
 
 The MVME5100 is a 6U form factor VME64 computer with:
 
   - A single MPC7410 or MPC750 CPU
   - A HAWK Processor Host Bridge (CPU to PCI) and
 MultiProcessor Interrupt Controller (MPIC)
   - Up to 500Mb of onboard memory
   - A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip
   - Two 16550 compatible UARTS
   - Two Intel E100 Fast Ethernets
   - Two PCI Mezzanine Card (PMC) Slots
   - PPCBug Firmware
 
 The HAWK PHB/MPIC is compatible with the MPC10x devices.
 
 There is no onboard disk support. This is usually provided by
 installing a PMC in the first PMC slot.
 
 This patch revives the board support, it was present in early 2.6
 series kernels. The board support in those days was by Matt Porter of
 MontaVista Software.
 
 CSC Australia has around 31 of these boards in service. The kernel in use
 for the boards is based on 2.6.31. The boards are operated without disks
 from a file server. 
 
 This patch is based on linux-3.12-rc7 and has been boot tested.
 
 V1-V2:
   Address comments by Kular Gama and Scott Wood.
   Minor adjustment to platforms/embedded6xx/Kconfig to ensure
   correct indentation where possible.
 
 V2-V3:
   Address comments by Scott Wood and Ben Herrenschmidt.
   Address errors reported by checkpatch.
 
 Signed-off-by: Stephen Chivers schiv...@csc.comA

Tested-by: Alessio Igor Bogani alessio.bog...@elettra.eu

 ---
  arch/powerpc/boot/Makefile|3 +-
  arch/powerpc/boot/dts/mvme5100.dts|  185 +
  arch/powerpc/boot/mvme5100.c  |   27 +++
  arch/powerpc/boot/wrapper |4 +
  arch/powerpc/configs/mvme5100_defconfig   |  144 
  arch/powerpc/platforms/embedded6xx/Kconfig|   13 ++-
  arch/powerpc/platforms/embedded6xx/Makefile   |1 +
  arch/powerpc/platforms/embedded6xx/mvme5100.c |  221 
 +
  8 files changed, 596 insertions(+), 2 deletions(-)
 
 diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
 index 15ca225..a1c9c86 100644
 --- a/arch/powerpc/boot/Makefile
 +++ b/arch/powerpc/boot/Makefile
 @@ -94,7 +94,7 @@ src-plat-$(CONFIG_FSL_SOC_BOOKE) += cuboot-85xx.c 
 cuboot-85xx-cpm2.c
  src-plat-$(CONFIG_EMBEDDED6xx) += cuboot-pq2.c cuboot-mpc7448hpc2.c \
   cuboot-c2k.c gamecube-head.S \
   gamecube.c wii-head.S wii.c holly.c \
 - prpmc2800.c
 + prpmc2800.c fixed-head.S mvme5100.c
  src-plat-$(CONFIG_AMIGAONE) += cuboot-amigaone.c
  src-plat-$(CONFIG_PPC_PS3) += ps3-head.S ps3-hvcall.S ps3.c
  src-plat-$(CONFIG_EPAPR_BOOT) += epapr.c epapr-wrapper.c
 @@ -285,6 +285,7 @@ image-$(CONFIG_MPC7448HPC2)   += 
 cuImage.mpc7448hpc2
  image-$(CONFIG_PPC_C2K)  += cuImage.c2k
  image-$(CONFIG_GAMECUBE) += dtbImage.gamecube
  image-$(CONFIG_WII)  += dtbImage.wii
 +image-$(CONFIG_MVME5100) += dtbImage.mvme5100
  
  # Board port in arch/powerpc/platform/amigaone/Kconfig
  image-$(CONFIG_AMIGAONE) += cuImage.amigaone
 diff --git a/arch/powerpc/boot/dts/mvme5100.dts 
 b/arch/powerpc/boot/dts/mvme5100.dts
 new file mode 100644
 index 000..4cb2f05
 --- /dev/null
 +++ b/arch/powerpc/boot/dts/mvme5100.dts
 @@ -0,0 +1,185 @@
 +/*
 + * Device Tree Souce for Motorola/Emerson MVME5100.
 + *
 + * Copyright 2013 CSC Australia Pty. Ltd.
 + *
 + * This file is licensed under the terms of the GNU General Public
 + * License version 2.  This program is licensed as is without
 + * any warranty of any kind, whether express or implied.
 + */
 +
 +/dts-v1/;
 +
 +/ {
 + model = MVME5100;
 + compatible = MVME5100;
 + #address-cells = 1;
 + #size-cells = 1;
 +
 + aliases {
 + serial0 = serial0;
 + pci0 = pci0;
 + };
 +
 + cpus {
 + #address-cells = 1;
 + #size-cells = 0;
 +
 + PowerPC,7410 {
 + device_type = cpu;
 + reg = 0x0;
 + /* Following required by dtc but not used */
 + d-cache-line-size = 32;
 + i-cache-line-size = 32;
 + i-cache-size = 32768;
 + d-cache-size = 32768;
 + timebase-frequency = 2500;
 + clock-frequency = 5;
 + bus-frequency = 1;
 + };
 + };
 +
 + memory {
 + device_type = memory;
 + reg = 0x0 0x2000;
 + };
 +
 + hawk@fef8 {
 + #address-cells = 1;
 + #size-cells = 1;
 + compatible = hawk-bridge, simple-bus;
 + 

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-06 Thread Paul E. McKenney
On Wed, Nov 06, 2013 at 02:57:36PM +0100, Peter Zijlstra wrote:
 On Wed, Nov 06, 2013 at 01:51:10PM +0100, Geert Uytterhoeven wrote:
  This is screaming for a default implementation in asm-generic.
 
 Right you are... how about a little something like this?
 
 There's a few archs I didn't fully merge with the generic one because of
 weird nop implementations.
 
 asm volatile (nop :: ) vs asm volatile (nop ::: memory) and the
 like. They probably can (and should) use the regular asm volatile
 (nop) but I misplaced the toolchains for many of the weird archs so I
 didn't attempt.
 
 Also fixed a silly mistake in the return type definition for most
 smp_load_acquire() implementions: typeof(p) vs typeof(*p).
 
 ---
 Subject: arch: Introduce smp_load_acquire(), smp_store_release()
 From: Peter Zijlstra pet...@infradead.org
 Date: Mon, 4 Nov 2013 20:18:11 +0100
 
 A number of situations currently require the heavyweight smp_mb(),
 even though there is no need to order prior stores against later
 loads.  Many architectures have much cheaper ways to handle these
 situations, but the Linux kernel currently has no portable way
 to make use of them.
 
 This commit therefore supplies smp_load_acquire() and
 smp_store_release() to remedy this situation.  The new
 smp_load_acquire() primitive orders the specified load against
 any subsequent reads or writes, while the new smp_store_release()
 primitive orders the specifed store against any prior reads or
 writes.  These primitives allow array-based circular FIFOs to be
 implemented without an smp_mb(), and also allow a theoretical
 hole in rcu_assign_pointer() to be closed at no additional
 expense on most architectures.
 
 In addition, the RCU experience transitioning from explicit
 smp_read_barrier_depends() and smp_wmb() to rcu_dereference()
 and rcu_assign_pointer(), respectively resulted in substantial
 improvements in readability.  It therefore seems likely that
 replacing other explicit barriers with smp_load_acquire() and
 smp_store_release() will provide similar benefits.  It appears
 that roughly half of the explicit barriers in core kernel code
 might be so replaced.
 
 
 Cc: Michael Ellerman mich...@ellerman.id.au
 Cc: Michael Neuling mi...@neuling.org
 Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
 Cc: Linus Torvalds torva...@linux-foundation.org
 Cc: Victor Kaplansky vict...@il.ibm.com
 Cc: Oleg Nesterov o...@redhat.com
 Cc: Anton Blanchard an...@samba.org
 Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
 Cc: Frederic Weisbecker fweis...@gmail.com
 Cc: Mathieu Desnoyers mathieu.desnoy...@polymtl.ca
 Signed-off-by: Peter Zijlstra pet...@infradead.org

A few nits on Documentation/memory-barriers.txt and some pointless
comments elsewhere.  With the suggested Documentation/memory-barriers.txt
fixes:

Reviewed-by: Paul E. McKenney paul...@linux.vnet.ibm.com

 ---
  Documentation/memory-barriers.txt |  157 
 +-
  arch/alpha/include/asm/barrier.h  |   25 +
  arch/arc/include/asm/Kbuild   |1 
  arch/arc/include/asm/atomic.h |5 +
  arch/arc/include/asm/barrier.h|   42 -
  arch/arm/include/asm/barrier.h|   15 +++
  arch/arm64/include/asm/barrier.h  |   50 ++
  arch/avr32/include/asm/barrier.h  |   17 +--
  arch/blackfin/include/asm/barrier.h   |   18 ---
  arch/cris/include/asm/Kbuild  |1 
  arch/cris/include/asm/barrier.h   |   25 -
  arch/frv/include/asm/barrier.h|8 -
  arch/h8300/include/asm/barrier.h  |   21 
  arch/hexagon/include/asm/Kbuild   |1 
  arch/hexagon/include/asm/barrier.h|   41 
  arch/ia64/include/asm/barrier.h   |   49 ++
  arch/m32r/include/asm/barrier.h   |   80 -
  arch/m68k/include/asm/barrier.h   |   14 ---
  arch/metag/include/asm/barrier.h  |   15 +++
  arch/microblaze/include/asm/Kbuild|1 
  arch/microblaze/include/asm/barrier.h |   27 -
  arch/mips/include/asm/barrier.h   |   15 +++
  arch/mn10300/include/asm/Kbuild   |1 
  arch/mn10300/include/asm/barrier.h|   37 
  arch/parisc/include/asm/Kbuild|1 
  arch/parisc/include/asm/barrier.h |   35 ---
  arch/powerpc/include/asm/barrier.h|   21 
  arch/s390/include/asm/barrier.h   |   15 +++
  arch/score/include/asm/Kbuild |1 
  arch/score/include/asm/barrier.h  |   16 ---
  arch/sh/include/asm/barrier.h |   21 
  arch/sparc/include/asm/barrier_32.h   |   11 --
  arch/sparc/include/asm/barrier_64.h   |   15 +++
  arch/tile/include/asm/barrier.h   |   68 --
  arch/unicore32/include/asm/barrier.h  |   11 --
  arch/x86/include/asm/barrier.h|   15 +++
  arch/xtensa/include/asm/barrier.h |9 -
  include/asm-generic/barrier.h |   55 +--
  include/linux/compiler.h  |9 +
  39 files changed, 375 insertions(+), 594 deletions(-)
 
 --- 

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-06 Thread Peter Zijlstra
On Wed, Nov 06, 2013 at 10:48:48AM -0800, Paul E. McKenney wrote:
 A few nits on Documentation/memory-barriers.txt and some pointless
 comments elsewhere.  With the suggested Documentation/memory-barriers.txt
 fixes:
 
 Reviewed-by: Paul E. McKenney paul...@linux.vnet.ibm.com

Thanks, I think I'll cut the thing into a number of smaller patches with
identical end result. Will (hopefully) post a full new series tomorrow
somewhere.

I was thinking like:
 1 - aggressively employ asm-generic/barrier.h
 2 - Reformulate _The_ document to ACQUIRE/RELEASE
 3 - add the new store/load thingies

That should hopefully be slightly easier to look at.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 3/3] powerpc/kvm: remove redundant assignment

2013-11-06 Thread Benjamin Herrenschmidt
On Wed, 2013-11-06 at 12:24 +0100, Alexander Graf wrote:
 On 05.11.2013, at 08:42, Liu Ping Fan kernelf...@gmail.com wrote:
 
  Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
 
 Patch description missing.

Do you really need a description for trivial one-lines whose subject
is a perfectly complete description already ?

 Please add Paul's ack in the next revision of this patch :).
 
 
 Alex
 
  ---
  arch/powerpc/kvm/book3s_64_mmu_hv.c | 1 -
  1 file changed, 1 deletion(-)
  
  diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
  b/arch/powerpc/kvm/book3s_64_mmu_hv.c
  index 28160ac..7682837 100644
  --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
  +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
  @@ -731,7 +731,6 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run, 
  struct kvm_vcpu *vcpu,
  lock_rmap(rmap);
  
  /* Check if we might have been invalidated; let the guest retry if so */
  -   ret = RESUME_GUEST;
  if (mmu_notifier_retry(vcpu-kvm, mmu_seq)) {
  unlock_rmap(rmap);
  goto out_unlock;
  -- 
  1.8.1.4
  
  --
  To unsubscribe from this list: send the line unsubscribe kvm-ppc in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH V7 2/7] pseries/cpuidle: Use cpuidle_register() for initialisation.

2013-11-06 Thread Daniel Lezcano

On 10/29/2013 12:01 PM, Deepthi Dharwar wrote:

This patch replaces the cpuidle driver and devices initialisation
calls with a single generic cpuidle_register() call
and also includes minor refactoring of the code around it.

Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com


Acked-by: Daniel Lezcano daniel.lezc...@linaro.org


---
  drivers/cpuidle/cpuidle-ibm-power.c |   80 +--
  1 file changed, 12 insertions(+), 68 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-ibm-power.c 
b/drivers/cpuidle/cpuidle-ibm-power.c
index a166e38..faf8cc1 100644
--- a/drivers/cpuidle/cpuidle-ibm-power.c
+++ b/drivers/cpuidle/cpuidle-ibm-power.c
@@ -1,5 +1,5 @@
  /*
- *  processor_idle - idle state cpuidle driver.
+ *  cpuidle-ibm-power - idle state cpuidle driver.
   *  Adapted from drivers/idle/intel_idle.c and
   *  drivers/acpi/processor_idle.c
   *
@@ -28,7 +28,6 @@ struct cpuidle_driver pseries_idle_driver = {
  #define MAX_IDLE_STATE_COUNT  2

  static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
-static struct cpuidle_device __percpu *pseries_cpuidle_devices;
  static struct cpuidle_state *cpuidle_state_table;

  static inline void idle_loop_prolog(unsigned long *in_purr)
@@ -56,13 +55,12 @@ static int snooze_loop(struct cpuidle_device *dev,
int index)
  {
unsigned long in_purr;
-   int cpu = dev-cpu;

idle_loop_prolog(in_purr);
local_irq_enable();
set_thread_flag(TIF_POLLING_NRFLAG);

-   while ((!need_resched())  cpu_online(cpu)) {
+   while (!need_resched()) {
ppc64_runlatch_off();
HMT_low();
HMT_very_low();
@@ -191,7 +189,7 @@ static int pseries_cpuidle_add_cpu_notifier(struct 
notifier_block *n,
  {
int hotcpu = (unsigned long)hcpu;
struct cpuidle_device *dev =
-   per_cpu_ptr(pseries_cpuidle_devices, hotcpu);
+   per_cpu(cpuidle_devices, hotcpu);

if (dev  cpuidle_get_driver()) {
switch (action) {
@@ -248,50 +246,6 @@ static int pseries_cpuidle_driver_init(void)
return 0;
  }

-/* pseries_idle_devices_uninit(void)
- * unregister cpuidle devices and de-allocate memory
- */
-static void pseries_idle_devices_uninit(void)
-{
-   int i;
-   struct cpuidle_device *dev;
-
-   for_each_possible_cpu(i) {
-   dev = per_cpu_ptr(pseries_cpuidle_devices, i);
-   cpuidle_unregister_device(dev);
-   }
-
-   free_percpu(pseries_cpuidle_devices);
-   return;
-}
-
-/* pseries_idle_devices_init()
- * allocate, initialize and register cpuidle device
- */
-static int pseries_idle_devices_init(void)
-{
-   int i;
-   struct cpuidle_driver *drv = pseries_idle_driver;
-   struct cpuidle_device *dev;
-
-   pseries_cpuidle_devices = alloc_percpu(struct cpuidle_device);
-   if (pseries_cpuidle_devices == NULL)
-   return -ENOMEM;
-
-   for_each_possible_cpu(i) {
-   dev = per_cpu_ptr(pseries_cpuidle_devices, i);
-   dev-state_count = drv-state_count;
-   dev-cpu = i;
-   if (cpuidle_register_device(dev)) {
-   printk(KERN_DEBUG \
-   cpuidle_register_device %d failed!\n, i);
-   return -EIO;
-   }
-   }
-
-   return 0;
-}
-
  /*
   * pseries_idle_probe()
   * Choose state table for shared versus dedicated partition
@@ -299,9 +253,6 @@ static int pseries_idle_devices_init(void)
  static int pseries_idle_probe(void)
  {

-   if (!firmware_has_feature(FW_FEATURE_SPLPAR))
-   return -ENODEV;
-
if (cpuidle_disable != IDLE_NO_OVERRIDE)
return -ENODEV;

@@ -310,10 +261,13 @@ static int pseries_idle_probe(void)
return -EPERM;
}

-   if (lppaca_shared_proc(get_lppaca()))
-   cpuidle_state_table = shared_states;
-   else
-   cpuidle_state_table = dedicated_states;
+   if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
+   if (lppaca_shared_proc(get_lppaca()))
+   cpuidle_state_table = shared_states;
+   else
+   cpuidle_state_table = dedicated_states;
+   } else
+   return -ENODEV;

return 0;
  }
@@ -327,22 +281,14 @@ static int __init pseries_processor_idle_init(void)
return retval;

pseries_cpuidle_driver_init();
-   retval = cpuidle_register_driver(pseries_idle_driver);
+   retval = cpuidle_register(pseries_idle_driver, NULL);
if (retval) {
printk(KERN_DEBUG Registration of pseries driver failed.\n);
return retval;
}

-   retval = pseries_idle_devices_init();
-   if (retval) {
-   pseries_idle_devices_uninit();
-   cpuidle_unregister_driver(pseries_idle_driver);
-   return 

Re: [PATCH V7 3/7] pseries/cpuidle: Make pseries_idle backend driver a non-module.

2013-11-06 Thread Daniel Lezcano

On 10/29/2013 12:01 PM, Deepthi Dharwar wrote:

Currently pseries_idle cpuidle backend driver cannot be
built as a module due to dependencies. Therefore the driver has
to be built in. The dependency is around update_snooze_delay() defined
in cpuidle driver and called from kernel/sysfs.c.
This patch is removes all the module related code.

Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com


Acked-by: Daniel Lezcano daniel.lezc...@linaro.org


---
  drivers/cpuidle/cpuidle-ibm-power.c |   15 +--
  1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-ibm-power.c 
b/drivers/cpuidle/cpuidle-ibm-power.c
index faf8cc1..8c9e42c 100644
--- a/drivers/cpuidle/cpuidle-ibm-power.c
+++ b/drivers/cpuidle/cpuidle-ibm-power.c
@@ -292,17 +292,4 @@ static int __init pseries_processor_idle_init(void)
return 0;
  }

-static void __exit pseries_processor_idle_exit(void)
-{
-
-   unregister_cpu_notifier(setup_hotplug_notifier);
-   cpuidle_unregister(pseries_idle_driver);
-   return;
-}
-
-module_init(pseries_processor_idle_init);
-module_exit(pseries_processor_idle_exit);
-
-MODULE_AUTHOR(Deepthi Dharwar deep...@linux.vnet.ibm.com);
-MODULE_DESCRIPTION(Cpuidle driver for POWER);
-MODULE_LICENSE(GPL);
+device_initcall(pseries_processor_idle_init);

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V7 4/7] pseries/cpuidle: Remove MAX_IDLE_STATE macro.

2013-11-06 Thread Daniel Lezcano

On 10/29/2013 12:01 PM, Deepthi Dharwar wrote:

This patch removes the usage of MAX_IDLE_STATE macro
and dead code around it. The number of states
are determined at run time based on the cpuidle
state table selected on a given platform

Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com


Acked-by: Daniel Lezcano daniel.lezc...@linaro.org


---
  drivers/cpuidle/cpuidle-ibm-power.c |   26 +-
  1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-ibm-power.c 
b/drivers/cpuidle/cpuidle-ibm-power.c
index 8c9e42c..e81c207 100644
--- a/drivers/cpuidle/cpuidle-ibm-power.c
+++ b/drivers/cpuidle/cpuidle-ibm-power.c
@@ -25,9 +25,7 @@ struct cpuidle_driver pseries_idle_driver = {
.owner= THIS_MODULE,
  };

-#define MAX_IDLE_STATE_COUNT   2
-
-static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
+static int max_idle_state;
  static struct cpuidle_state *cpuidle_state_table;

  static inline void idle_loop_prolog(unsigned long *in_purr)
@@ -137,7 +135,7 @@ static int shared_cede_loop(struct cpuidle_device *dev,
  /*
   * States for dedicated partition case.
   */
-static struct cpuidle_state dedicated_states[MAX_IDLE_STATE_COUNT] = {
+static struct cpuidle_state dedicated_states[] = {
{ /* Snooze */
.name = snooze,
.desc = snooze,
@@ -157,7 +155,7 @@ static struct cpuidle_state 
dedicated_states[MAX_IDLE_STATE_COUNT] = {
  /*
   * States for shared partition case.
   */
-static struct cpuidle_state shared_states[MAX_IDLE_STATE_COUNT] = {
+static struct cpuidle_state shared_states[] = {
{ /* Shared Cede */
.name = Shared Cede,
.desc = Shared Cede,
@@ -227,11 +225,7 @@ static int pseries_cpuidle_driver_init(void)
struct cpuidle_driver *drv = pseries_idle_driver;

drv-state_count = 0;
-
-   for (idle_state = 0; idle_state  MAX_IDLE_STATE_COUNT; ++idle_state) {
-
-   if (idle_state  max_idle_state)
-   break;
+   for (idle_state = 0; idle_state  max_idle_state; ++idle_state) {

/* is the state not enabled? */
if (cpuidle_state_table[idle_state].enter == NULL)
@@ -256,16 +250,14 @@ static int pseries_idle_probe(void)
if (cpuidle_disable != IDLE_NO_OVERRIDE)
return -ENODEV;

-   if (max_idle_state == 0) {
-   printk(KERN_DEBUG pseries processor idle disabled.\n);
-   return -EPERM;
-   }
-
if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
-   if (lppaca_shared_proc(get_lppaca()))
+   if (lppaca_shared_proc(get_lppaca())) {
cpuidle_state_table = shared_states;
-   else
+   max_idle_state = ARRAY_SIZE(shared_states);
+   } else {
cpuidle_state_table = dedicated_states;
+   max_idle_state = ARRAY_SIZE(dedicated_states);
+   }
} else
return -ENODEV;





--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V7 5/7] POWER/cpuidle: Generic POWER CPUIDLE driver supporting PSERIES.

2013-11-06 Thread Daniel Lezcano

On 10/29/2013 12:01 PM, Deepthi Dharwar wrote:

This patch includes cleanup and refactoring of the
existing code to make the driver POWER generic.
* Re-naming the functions from pseries to generic power.
* Re-naming the backend driver from pseries_idle to
   ibm-power-idle.

Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com


Acked-by: Daniel Lezcano daniel.lezc...@linaro.org

... but I am wondering if 'power' name is not confusing with power 
management and if 'powerpc' would suit better.



---
  drivers/cpuidle/cpuidle-ibm-power.c |   32 
  1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-ibm-power.c 
b/drivers/cpuidle/cpuidle-ibm-power.c
index e81c207..5b92242 100644
--- a/drivers/cpuidle/cpuidle-ibm-power.c
+++ b/drivers/cpuidle/cpuidle-ibm-power.c
@@ -20,8 +20,8 @@
  #include asm/runlatch.h
  #include asm/plpar_wrappers.h

-struct cpuidle_driver pseries_idle_driver = {
-   .name = pseries_idle,
+struct cpuidle_driver power_idle_driver = {
+   .name = ibm_power_idle,
.owner= THIS_MODULE,
  };

@@ -182,7 +182,7 @@ void update_smt_snooze_delay(int cpu, int residency)
drv-states[1].target_residency = residency;
  }

-static int pseries_cpuidle_add_cpu_notifier(struct notifier_block *n,
+static int power_cpuidle_add_cpu_notifier(struct notifier_block *n,
unsigned long action, void *hcpu)
  {
int hotcpu = (unsigned long)hcpu;
@@ -213,16 +213,16 @@ static int pseries_cpuidle_add_cpu_notifier(struct 
notifier_block *n,
  }

  static struct notifier_block setup_hotplug_notifier = {
-   .notifier_call = pseries_cpuidle_add_cpu_notifier,
+   .notifier_call = power_cpuidle_add_cpu_notifier,
  };

  /*
- * pseries_cpuidle_driver_init()
+ * power_cpuidle_driver_init()
   */
-static int pseries_cpuidle_driver_init(void)
+static int power_cpuidle_driver_init(void)
  {
int idle_state;
-   struct cpuidle_driver *drv = pseries_idle_driver;
+   struct cpuidle_driver *drv = power_idle_driver;

drv-state_count = 0;
for (idle_state = 0; idle_state  max_idle_state; ++idle_state) {
@@ -241,10 +241,10 @@ static int pseries_cpuidle_driver_init(void)
  }

  /*
- * pseries_idle_probe()
+ * power_idle_probe()
   * Choose state table for shared versus dedicated partition
   */
-static int pseries_idle_probe(void)
+static int power_idle_probe(void)
  {

if (cpuidle_disable != IDLE_NO_OVERRIDE)
@@ -264,24 +264,24 @@ static int pseries_idle_probe(void)
return 0;
  }

-static int __init pseries_processor_idle_init(void)
+static int __init power_processor_idle_init(void)
  {
int retval;

-   retval = pseries_idle_probe();
+   retval = power_idle_probe();
if (retval)
return retval;

-   pseries_cpuidle_driver_init();
-   retval = cpuidle_register(pseries_idle_driver, NULL);
+   power_cpuidle_driver_init();
+   retval = cpuidle_register(power_idle_driver, NULL);
if (retval) {
-   printk(KERN_DEBUG Registration of pseries driver failed.\n);
+   printk(KERN_DEBUG Registration of ibm_power_idle driver 
failed.\n);
return retval;
}

register_cpu_notifier(setup_hotplug_notifier);
-   printk(KERN_DEBUG pseries_idle_driver registered\n);
+   printk(KERN_DEBUG ibm_power_idle registered\n);
return 0;
  }

-device_initcall(pseries_processor_idle_init);
+device_initcall(power_processor_idle_init);




--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V7 6/7] POWER/cpuidle: Enable powernv cpuidle support.

2013-11-06 Thread Daniel Lezcano

On 10/29/2013 12:01 PM, Deepthi Dharwar wrote:

The following patch extends the current power backend
idle driver to the powernv platform.

Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com


Acked-by: Daniel Lezcano daniel.lezc...@linaro.org


---
  drivers/cpuidle/cpuidle-ibm-power.c |   39 ---
  1 file changed, 36 insertions(+), 3 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-ibm-power.c 
b/drivers/cpuidle/cpuidle-ibm-power.c
index 5b92242..f790ea2 100644
--- a/drivers/cpuidle/cpuidle-ibm-power.c
+++ b/drivers/cpuidle/cpuidle-ibm-power.c
@@ -52,9 +52,10 @@ static int snooze_loop(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
  {
-   unsigned long in_purr;
+   unsigned long in_purr = 0;

-   idle_loop_prolog(in_purr);
+   if (firmware_has_feature(FW_FEATURE_SPLPAR))
+   idle_loop_prolog(in_purr);
local_irq_enable();
set_thread_flag(TIF_POLLING_NRFLAG);

@@ -68,7 +69,8 @@ static int snooze_loop(struct cpuidle_device *dev,
clear_thread_flag(TIF_POLLING_NRFLAG);
smp_mb();

-   idle_loop_epilog(in_purr);
+   if (firmware_has_feature(FW_FEATURE_SPLPAR))
+   idle_loop_epilog(in_purr);

return index;
  }
@@ -132,6 +134,15 @@ static int shared_cede_loop(struct cpuidle_device *dev,
return index;
  }

+static int nap_loop(struct cpuidle_device *dev,
+   struct cpuidle_driver *drv,
+   int index)
+{
+   ppc64_runlatch_off();
+   power7_idle();
+   return index;
+}
+
  /*
   * States for dedicated partition case.
   */
@@ -165,6 +176,23 @@ static struct cpuidle_state shared_states[] = {
.enter = shared_cede_loop },
  };

+static struct cpuidle_state powernv_states[] = {
+   { /* Snooze */
+   .name = snooze,
+   .desc = snooze,
+   .flags = CPUIDLE_FLAG_TIME_VALID,
+   .exit_latency = 0,
+   .target_residency = 0,
+   .enter = snooze_loop },
+   { /* NAP */
+   .name = NAP,
+   .desc = NAP,
+   .flags = CPUIDLE_FLAG_TIME_VALID,
+   .exit_latency = 10,
+   .target_residency = 100,
+   .enter = nap_loop },
+};
+
  void update_smt_snooze_delay(int cpu, int residency)
  {
struct cpuidle_driver *drv = cpuidle_get_driver();
@@ -258,6 +286,11 @@ static int power_idle_probe(void)
cpuidle_state_table = dedicated_states;
max_idle_state = ARRAY_SIZE(dedicated_states);
}
+
+   } else if (firmware_has_feature(FW_FEATURE_OPALv3)) {
+   cpuidle_state_table = powernv_states;
+   max_idle_state = ARRAY_SIZE(powernv_states);
+
} else
return -ENODEV;





--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V7 7/7] powernv/cpuidle: Enable idle powernv cpu to call into the cpuidle framework.

2013-11-06 Thread Daniel Lezcano

On 10/29/2013 12:02 PM, Deepthi Dharwar wrote:

This patch enables idle cpu on the powernv platform  to hook on to the cpuidle
framework, if available, else call on to default idle platform
code.

Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com


Acked-by: Daniel Lezcano daniel.lezc...@linaro.org


---
  arch/powerpc/platforms/powernv/setup.c |   13 -
  1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/setup.c 
b/arch/powerpc/platforms/powernv/setup.c
index e239dcf..42a6ba0 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -25,6 +25,7 @@
  #include linux/of.h
  #include linux/interrupt.h
  #include linux/bug.h
+#include linux/cpuidle.h

  #include asm/machdep.h
  #include asm/firmware.h
@@ -192,6 +193,16 @@ static void __init pnv_setup_machdep_rtas(void)
  }
  #endif /* CONFIG_PPC_POWERNV_RTAS */

+void powernv_idle(void)
+{
+   /* Hook to cpuidle framework if available, else
+* call on default platform idle code
+*/
+   if (cpuidle_idle_call()) {
+   power7_idle();
+   }
+}
+
  static int __init pnv_probe(void)
  {
unsigned long root = of_get_flat_dt_root();
@@ -222,7 +233,7 @@ define_machine(powernv) {
.show_cpuinfo   = pnv_show_cpuinfo,
.progress   = pnv_progress,
.machine_shutdown   = pnv_shutdown,
-   .power_save = power7_idle,
+   .power_save = powernv_idle,
.calibrate_decr = generic_calibrate_decr,
  #ifdef CONFIG_KEXEC
.kexec_cpu_down = pnv_kexec_cpu_down,




--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

2013-11-06 Thread Scott Wood
On Wed, 2013-11-06 at 01:50 -0600, Wang Dongsheng-B40534 wrote:
 
  -Original Message-
  From: Bhushan Bharat-R65777
  Sent: Wednesday, November 06, 2013 1:25 PM
  To: Wang Dongsheng-B40534; Wood Scott-B07421
  Cc: linuxppc-dev@lists.ozlabs.org
  Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
  altivec idle
  
  
  
   -Original Message-
   From: Wang Dongsheng-B40534
   Sent: Tuesday, November 05, 2013 8:40 AM
   To: Wood Scott-B07421
   Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
   Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
   altivec idle
  
  
  
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, November 05, 2013 5:52 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
   
On Sun, 2013-11-03 at 22:04 -0600, Wang Dongsheng-B40534 wrote:
  -Original Message-
  From: Wang Dongsheng-B40534
  Sent: Monday, October 21, 2013 11:11 AM
  To: Wood Scott-B07421
  Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
  Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
  state and altivec idle
 
 
 
   -Original Message-
   From: Wood Scott-B07421
   Sent: Saturday, October 19, 2013 3:22 AM
   To: Wang Dongsheng-B40534
   Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
   d...@lists.ozlabs.org
   Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
   state and altivec idle
  
   On Thu, 2013-10-17 at 22:02 -0500, Wang Dongsheng-B40534 wrote:
   
 -Original Message-
 From: Bhushan Bharat-R65777
 Sent: Thursday, October 17, 2013 2:46 PM
 To: Wang Dongsheng-B40534; Wood Scott-B07421
 Cc: linuxppc-dev@lists.ozlabs.org
 Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for
 pw20 state and altivec idle



-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, October 17, 2013 11:22 AM
To: Bhushan Bharat-R65777; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs
for
pw20 state and altivec idle
   
   
   
 -Original Message-
 From: Bhushan Bharat-R65777
 Sent: Thursday, October 17, 2013 11:20 AM
 To: Wang Dongsheng-B40534; Wood Scott-B07421
 Cc: linuxppc-dev@lists.ozlabs.org
 Subject: RE: [PATCH v5 4/4] powerpc/85xx: add
 sysfs for
 pw20 state and altivec idle



  -Original Message-
  From: Wang Dongsheng-B40534
  Sent: Thursday, October 17, 2013 8:16 AM
  To: Bhushan Bharat-R65777; Wood Scott-B07421
  Cc: linuxppc-dev@lists.ozlabs.org
  Subject: RE: [PATCH v5 4/4] powerpc/85xx: add
  sysfs for
  pw20 state and altivec idle
 
 
 
   -Original Message-
   From: Bhushan Bharat-R65777
   Sent: Thursday, October 17, 2013 1:01 AM
   To: Wang Dongsheng-B40534; Wood Scott-B07421
   Cc: linuxppc-dev@lists.ozlabs.org
   Subject: RE: [PATCH v5 4/4] powerpc/85xx: add
   sysfs for
   pw20 state and altivec idle
  
  
  
-Original Message-
From: Wang Dongsheng-B40534
Sent: Tuesday, October 15, 2013 2:51 PM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777;
linuxppc-dev@lists.ozlabs.org; Wang
   Dongsheng-B40534
Subject: [PATCH v5 4/4] powerpc/85xx: add
sysfs for
pw20 state and
   altivec idle
   
From: Wang Dongsheng
dongsheng.w...@freescale.com
   
Add a sys interface to enable/diable pw20
state or altivec idle, and
   control the
wait entry time.
   
Enable/Disable interface:
0, disable. 1, enable.
/sys/devices/system/cpu/cpuX/pw20_state
/sys/devices/system/cpu/cpuX/altivec_idle
   
Set wait time interface:(Nanosecond)
/sys/devices/system/cpu/cpuX/pw20_wait_time
/sys/devices/system/cpu/cpuX/altivec_idle_wa
it
_t
ime
Example: Base on TBfreq is 41MHZ.

[PATCH 4/4] powerpc: ELF2 binaries signal handling

2013-11-06 Thread Rusty Russell
For the ELFv2 ABI, the hander is the entry point, not a function descriptor.
We also need to set up r12, and fortunately the fast_exception_return
exit path restores r12 for us so nothing else is required.

Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
 arch/powerpc/kernel/signal_64.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
index f7e61e0..af1f7ad 100644
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -694,12 +694,6 @@ badframe:
 int handle_rt_signal64(int signr, struct k_sigaction *ka, siginfo_t *info,
sigset_t *set, struct pt_regs *regs)
 {
-   /* Handler is *really* a pointer to the function descriptor for
-* the signal routine.  The first entry in the function
-* descriptor is the entry address of signal and the second
-* entry is the TOC value we need to use.
-*/
-   func_descr_t __user *funct_desc_ptr;
struct rt_sigframe __user *frame;
unsigned long newsp = 0;
long err = 0;
@@ -759,19 +753,32 @@ int handle_rt_signal64(int signr, struct k_sigaction *ka, 
siginfo_t *info,
goto badframe;
regs-link = (unsigned long) frame-tramp[0];
}
-   funct_desc_ptr = (func_descr_t __user *) ka-sa.sa_handler;
 
/* Allocate a dummy caller frame for the signal handler. */
newsp = ((unsigned long)frame) - __SIGNAL_FRAMESIZE;
err |= put_user(regs-gpr[1], (unsigned long __user *)newsp);
 
/* Set up regs so we return to the signal handler. */
-   err |= get_user(regs-nip, funct_desc_ptr-entry);
+   if (is_elf2_task()) {
+   regs-nip = (unsigned long) ka-sa.sa_handler;
+   regs-gpr[12] = regs-nip;
+   } else {
+   /* Handler is *really* a pointer to the function descriptor for
+* the signal routine.  The first entry in the function
+* descriptor is the entry address of signal and the second
+* entry is the TOC value we need to use.
+*/
+   func_descr_t __user *funct_desc_ptr =
+   (func_descr_t __user *) ka-sa.sa_handler;
+
+   err |= get_user(regs-nip, funct_desc_ptr-entry);
+   err |= get_user(regs-gpr[2], funct_desc_ptr-toc);
+   }
+
/* enter the signal handler in native-endian mode */
regs-msr = ~MSR_LE;
regs-msr |= (MSR_KERNEL  MSR_LE);
regs-gpr[1] = newsp;
-   err |= get_user(regs-gpr[2], funct_desc_ptr-toc);
regs-gpr[3] = signr;
regs-result = 0;
if (ka-sa.sa_flags  SA_SIGINFO) {
-- 
1.8.3.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 3/4] powerpc: ELF2 binaries launched directly.

2013-11-06 Thread Rusty Russell
No function descriptor, but we set r12 up and set TIF_RESTOREALL as it
normally isn't restored on return from syscall.

Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
 arch/powerpc/kernel/process.c | 50 ++-
 1 file changed, 35 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 59967ea..6fa271a 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1078,25 +1078,45 @@ void start_thread(struct pt_regs *regs, unsigned long 
start, unsigned long sp)
regs-msr = MSR_USER;
 #else
if (!is_32bit_task()) {
-   unsigned long entry, toc;
+   unsigned long entry;
 
-   /* start is a relocated pointer to the function descriptor for
-* the elf _start routine.  The first entry in the function
-* descriptor is the entry address of _start and the second
-* entry is the TOC value we need to use.
-*/
-   __get_user(entry, (unsigned long __user *)start);
-   __get_user(toc, (unsigned long __user *)start+1);
+   if (is_elf2_task()) {
+   /* Look ma, no function descriptors! */
+   entry = start;
 
-   /* Check whether the e_entry function descriptor entries
-* need to be relocated before we can use them.
-*/
-   if (load_addr != 0) {
-   entry += load_addr;
-   toc   += load_addr;
+   /*
+* Ulrich says:
+*   The latest iteration of the ABI requires that when
+*   calling a function (at its global entry point),
+*   the caller must ensure r12 holds the entry point
+*   address (so that the function can quickly
+*   establish addressability).
+*/
+   regs-gpr[12] = start;
+   /* Make sure that's restored on entry to userspace. */
+   set_thread_flag(TIF_RESTOREALL);
+   } else {
+   unsigned long toc;
+
+   /* start is a relocated pointer to the function
+* descriptor for the elf _start routine.  The first
+* entry in the function descriptor is the entry
+* address of _start and the second entry is the TOC
+* value we need to use.
+*/
+   __get_user(entry, (unsigned long __user *)start);
+   __get_user(toc, (unsigned long __user *)start+1);
+
+   /* Check whether the e_entry function descriptor entries
+* need to be relocated before we can use them.
+*/
+   if (load_addr != 0) {
+   entry += load_addr;
+   toc   += load_addr;
+   }
+   regs-gpr[2] = toc;
}
regs-nip = entry;
-   regs-gpr[2] = toc;
regs-msr = MSR_USER64;
} else {
regs-nip = start;
-- 
1.8.3.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 1/4] powerpc: Add TIF_ELF2ABI flag.

2013-11-06 Thread Rusty Russell
Little endian ppc64 is getting an exciting new ABI.  This is reflected
by the bottom two bits of e_flags in the ELF header:

0 == legacy binaries (v1 ABI)
1 == binaries using the old ABI (compiled with a new toolchain)
2 == binaries using the new ABI.

We store this in a thread flag, because we need to set it in core
dumps and for signal delivery.  Our chief concern is that it doesn't
use function descriptors.

Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
 arch/powerpc/include/asm/elf.h | 4 
 arch/powerpc/include/asm/thread_info.h | 9 +
 2 files changed, 13 insertions(+)

diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index ac6ec6e..54c7445 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -85,6 +85,8 @@ typedef elf_vrregset_t elf_fpxregset_t;
 # ifdef CONFIG_COMPAT
 #  define SET_PERSONALITY(ex)  \
 do {   \
+   if (((ex).e_flags  0x3) == 2)  \
+   set_thread_flag(TIF_ELF2ABI);   \
if ((ex).e_ident[EI_CLASS] == ELFCLASS32)   \
set_thread_flag(TIF_32BIT); \
else\
@@ -96,6 +98,8 @@ do {  
\
 # else /* !COMPAT: */
 #  define SET_PERSONALITY(ex)  \
 do {   \
+   if (((ex).e_flags  0x3) == 2)  \
+   set_thread_flag(TIF_ELF2ABI);   \
if (personality(current-personality) != PER_LINUX32)   \
set_personality(PER_LINUX | \
(current-personality  (~PER_MASK)));  \
diff --git a/arch/powerpc/include/asm/thread_info.h 
b/arch/powerpc/include/asm/thread_info.h
index f66c2c1..460326f 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -109,6 +109,9 @@ static inline struct thread_info *current_thread_info(void)
 #define TIF_EMULATE_STACK_STORE16  /* Is an instruction emulation
for stack store? */
 #define TIF_MEMDIE 17  /* is terminating due to OOM killer */
+#if defined(CONFIG_PPC64)
+#define TIF_ELF2ABI18  /* function descriptors must die! */
+#endif
 
 /* as above, but as bit values */
 #define _TIF_SYSCALL_TRACE (1TIF_SYSCALL_TRACE)
@@ -193,6 +196,12 @@ static inline bool test_thread_local_flags(unsigned int 
flags)
 #define is_32bit_task()(1)
 #endif
 
+#if defined(CONFIG_PPC64)
+#define is_elf2_task() (test_thread_flag(TIF_ELF2ABI))
+#else
+#define is_elf2_task() (0)
+#endif
+
 #endif /* !__ASSEMBLY__ */
 
 #endif /* __KERNEL__ */
-- 
1.8.3.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 2/4] powerpc: Set eflags correctly for ELF ABIv2 core dumps.

2013-11-06 Thread Rusty Russell
We leave it at zero (though it could be 1) for old tasks.

Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
 arch/powerpc/include/asm/elf.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index 54c7445..8b89268 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -106,6 +106,8 @@ do {
\
 } while (0)
 # endif /* COMPAT */
 
+#define ELF_CORE_EFLAGS (is_elf2_task() ? 2 : 0)
+
 /*
  * An executable for which elf_read_implies_exec() returns TRUE will
  * have the READ_IMPLIES_EXEC personality flag set automatically. This
-- 
1.8.3.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc: memcpy optimization for 64bit LE

2013-11-06 Thread Anton Blanchard

Hi,

  Unaligned stores take alignment exceptions on POWER7 running in
  little-endian. This is a dumb little-endian base memcpy that
  prevents unaligned stores. It is replaced by the VMX memcpy at boot.
 
 Is this any faster than the generic version?

Once booted the feature fixup code switches us over to the VMX copy
loops (which are already endian safe).

The question is what we do before that switch over. The base 64bit
memcpy takes alignment exceptions on POWER7 so we can't use it as is.
Fixing the causes of alignment exception would slow it down, because
we'd need to ensure all loads and stores are aligned either through
rotate tricks or bytewise loads and stores. Either would be bad for
all other 64bit platforms.

Anton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc: memcpy optimization for 64bit LE

2013-11-06 Thread Michael Neuling
OK, can you add that and/or maybe antons description to the patch changelog?

Mikey

On Wed, Nov 6, 2013 at 9:21 PM, Philippe Bergheaud
fe...@linux.vnet.ibm.com wrote:
 Michael Neuling wrote:

 Philippe Bergheaud fe...@linux.vnet.ibm.com wrote:


 Unaligned stores take alignment exceptions on POWER7 running in
 little-endian.
 This is a dumb little-endian base memcpy that prevents unaligned stores.
 It is replaced by the VMX memcpy at boot.



 Is this any faster than the generic version?


 The little-endian assembly code of the base memcpy is similar to the code
 emitted by gcc when compiling the generic memcpy in lib/string.c, and runs
 at the same speed.
 However, a little-endian assembly version of the base memcpy is required (as
 opposed to a C version), in order to use the self-modifying code
 instrumentation system.
 After the cpu feature CPU_FTR_ALTIVEC is detected at boot, the slow base
 memcpy is nop'ed out, and the fast memcpy_power7 is used instead.

 Philippe

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH] ehci-platform: Merge ppc-of EHCI driver into the ehci-platform driver

2013-11-06 Thread Alistair Popple
On Wed, 6 Nov 2013 11:14:44 Alan Stern wrote:
 On Wed, 6 Nov 2013, Alistair Popple wrote:

[snip]

  +   /* Initialise platform data from device tree if available. */
  +   if (!dn) {
 
 Shouldn't this be if (dn)?

Yep. Thanks.

  +   if (of_get_property(dn, big-endian, NULL)) {
  +   pdata-big_endian_mmio = 1;
  +   pdata-big_endian_desc = 1;
  +   }
  +   if (of_get_property(dn, big-endian-regs, NULL))
  +   pdata-big_endian_mmio = 1;
  +   if (of_get_property(dn, big-endian-desc, NULL))
  +   pdata-big_endian_desc = 1;
  +   }
  +
 
 This isn't good if there is more than one EHCI controller using
 ehci-platform.  To accomodate such cases, it would be necessary to
 allocate a separate copy of ehci_platform_defaults for each controller.

OK, that's a problem. Rather than allocating platform data for each controller 
I will move the device tree parsing into ehci_platform_reset().

 Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH] ehci-platform: Merge ppc-of EHCI driver into the ehci-platform driver

2013-11-06 Thread Alistair Popple
On Thu, 7 Nov 2013 06:57:00 Benjamin Herrenschmidt wrote:
 On Wed, 2013-11-06 at 18:39 +1100, Alistair Popple wrote:

[snip]

 
 I would go even further and add the 44x workarounds to the normal
 platform device, with a compatible check in there. That isn't the
 first time we add quirks to an existing driver.

Ok, easily done. I guess I was just cautious of adding a bunch of platform 
specific code into an otherwise generic driver as there seems to be a number 
of other platforms with their own quirks and it would be easy to end up with a 
driver full of platform specific quirks.

That said it is probably better than the current situation in which each 
platform has its own copy/variation of the generic code in ehci-platform.

Unless anyone is against this I will merge the 440EPX specific quirks into the 
ehci-platform driver and submit it as part of the next version of the Akebono 
patch series.

  +   /* Initialise platform data from device tree if available. */
  +   if (!dn) {
 
 That was supposed to be if (dn) no ?

It sure was, thanks.

 
  +   if (of_get_property(dn, big-endian, NULL)) {
  +   pdata-big_endian_mmio = 1;
  +   pdata-big_endian_desc = 1;
  +   }
  +   if (of_get_property(dn, big-endian-regs, NULL))
  +   pdata-big_endian_mmio = 1;
  +   if (of_get_property(dn, big-endian-desc, NULL))
  +   pdata-big_endian_desc = 1;
  +   }
  +
  
  irq = platform_get_irq(dev, 0);
  if (irq  0) {
  
  dev_err(dev-dev, no irq provided);
  
  @@ -203,9 +216,10 @@ static int ehci_platform_resume(struct device *dev)
  
   #define ehci_platform_resume   NULL
   #endif /* CONFIG_PM */
  
  -static const struct of_device_id vt8500_ehci_ids[] = {
  +static const struct of_device_id ehci_platform_ids[] = {
  
  { .compatible = via,vt8500-ehci, },
  { .compatible = wm,prizm-ehci, },
  
  +   { .compatible = usb-ehci, },
  
  {}
   
   };
 
 Cheers,
 Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 2/3] powerpc/kvm: fix rare but potential deadlock scene

2013-11-06 Thread Liu ping fan
On Wed, Nov 6, 2013 at 7:18 PM, Paul Mackerras pau...@samba.org wrote:
 On Wed, Nov 06, 2013 at 02:02:07PM +0800, Liu ping fan wrote:
 On Wed, Nov 6, 2013 at 1:04 PM, Paul Mackerras pau...@samba.org wrote:
  On Tue, Nov 05, 2013 at 03:42:43PM +0800, Liu Ping Fan wrote:
  Since kvmppc_hv_find_lock_hpte() is called from both virtmode and
  realmode, so it can trigger the deadlock.
 
  Good catch, we should have preemption disabled while ever we have a
  HPTE locked.
 
  @@ -474,8 +474,10 @@ static int kvmppc_mmu_book3s_64_hv_xlate(struct 
  kvm_vcpu *vcpu, gva_t eaddr,
}
 
/* Find the HPTE in the hash table */
  + preempt_disable();
index = kvmppc_hv_find_lock_hpte(kvm, eaddr, slb_v,
 HPTE_V_VALID | HPTE_V_ABSENT);
  + preempt_enable();
 
  Which means we need to add the preempt_enable after unlocking the
  HPTE, not here.
 
 Yes. Sorry, but I am not sure about whether we can call
 preempt_disable/enable() in realmode. I think since thread_info is
 allocated with linear address, so we can use preempt_disable/enable()
 inside kvmppc_hv_find_lock_hpte(), right?

 Your analysis correctly pointed out that we can get a deadlock if we
 can be preempted while holding a lock on a HPTE.  That means that we
 have to disable preemption before taking an HPTE lock and keep it
 disabled until after we unlock the HPTE.  Since the point of
 kvmppc_hv_find_lock_hpte() is to lock the HPTE and return with it
 locked, we can't have the preempt_enable() inside it.  The
 preempt_enable() has to come after we have unlocked the HPTE.  That is
 also why we can't have the preempt_enable() where your patch put it;
 it needs to be about 9 lines further down, after the statement
 hptep[0] = v.  (We also need to make sure to re-enable preemption in
 the index  0 case.)

Oh, yes, will fix like what you said. My attention is attracted by the
trick of calling kernel func in realmode, and miss the exact point
where the lock is released.

Thanks and regards,
Pingfan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver

2013-11-06 Thread Alistair Popple
On Wed, 6 Nov 2013 16:40:10 Ben Hutchings wrote:
 On Wed, 2013-11-06 at 12:34 +1100, Alistair Popple wrote:
  On Tue, 5 Nov 2013 23:11:50 Ben Hutchings wrote:
   On Wed, 2013-11-06 at 06:54 +1100, Benjamin Herrenschmidt wrote:
  [snip]
  
It's an SoC bit so there's little point making it generally
selectable by the user.
   
   I think a better way to do this is:
   
   config IBM_EMAC_RGMII_WOL
   
 bool IBM EMAC RGMII wake-on-LAN support
 depends on MY_WONDERFUL_NEW_SOC || COMPILE_TEST
 default y if MY_WONDERFUL_NEW_SOC
   
   Then anyone making an API change that affects this driver can check that
   it still complies.
  
  The method used in this patch is the same as what is currently used by the
  other IBM EMAC PHY interfaces (eg. config IBM_EMAC_ZMII etc). I'm happy to
  send a patch to update all of those as well for consistency but that would
  mean adding what each platform requires into EMACS Kconfig as well.
  
  Personally I think it is nicer to keep the definitions of what each
  platform requires in one place (ie. arch/powerpc/platforms/44x/Kconfig)
  as it is consistent with what we do for other 44x drivers, however I am
  happy to use the above method if people think it's better.
 
 Yes, I see your point.
 
  Alternatively we could do something like this:
  
  config IBM_EMAC_RGMII_WOL
  
  bool
  default y if COMPILE_TEST
  default n
  
  This would leave the platform dependencies as they are currently but still
  allow compile testing.
 
 It still shouldn't default to y in that case.  Instead you can make the
 symbol conditionally configurable:
 
 config IBM_EMAC_RGMII_WOL
   bool IBM EMAC RGMII wake-on-LAN support if COMPILE_TEST
 
 and then select this from your platform Kconfig as you intended.

That looks reasonable - I will include it in the next version of the patch 
series. Thanks.

 (There is no need to put 'default n' as that's implicit for a
 configurable symbol.  But it doesn't hurt either.)
 
 Ben.

Alistair
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: [PATCHv2 5/8] ASoC: SGTL5000: Enhance the SGTL5000 codec driver about regulator.

2013-11-06 Thread Li Xiubo
  The SGTL5000 is based on regulators and when it is disabled, there
  will be an error returns directly while the SGTL5000 codec is probing.
 
 What makes you say this?  


From the code:
File path: sound/soc/codecs/sgtl5000.c
==
#ifdef CONFIG_REGULATOR
.
#else
static int ldo_regulator_register(struct snd_soc_codec *codec,
struct regulator_init_data *init_data,
int voltage)
{
dev_err(codec-dev, this setup needs regulator support in the 
kernel\n);
return -EINVAL;
}

static int ldo_regulator_remove(struct snd_soc_codec *codec)
{
return 0;
}
#endif
---

sgtl5000_probe() --
sgtl5000_enable_regulators() --
sgtl5000_replace_vddd_with_ldo() --
ldo_regulator_register().


 That's not how the regulator API works.  Have
 you actually seen any problems?

There are some regulator APIs implemented by SGTL5000 driver, not the regulator 
subsystem APIs.




___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

2013-11-06 Thread Dongsheng Wang


 -Original Message-
 From: Wood Scott-B07421
 Sent: Thursday, November 07, 2013 9:20 AM
 To: Wang Dongsheng-B40534
 Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
 d...@lists.ozlabs.org
 Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
 altivec idle
 
 On Wed, 2013-11-06 at 01:50 -0600, Wang Dongsheng-B40534 wrote:
 
   -Original Message-
   From: Bhushan Bharat-R65777
   Sent: Wednesday, November 06, 2013 1:25 PM
   To: Wang Dongsheng-B40534; Wood Scott-B07421
   Cc: linuxppc-dev@lists.ozlabs.org
   Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
   and altivec idle
  
  
  
-Original Message-
From: Wang Dongsheng-B40534
Sent: Tuesday, November 05, 2013 8:40 AM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
   
   
   
 -Original Message-
 From: Wood Scott-B07421
 Sent: Tuesday, November 05, 2013 5:52 AM
 To: Wang Dongsheng-B40534
 Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc-
 d...@lists.ozlabs.org
 Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
 state and altivec idle

 On Sun, 2013-11-03 at 22:04 -0600, Wang Dongsheng-B40534 wrote:
   -Original Message-
   From: Wang Dongsheng-B40534
   Sent: Monday, October 21, 2013 11:11 AM
   To: Wood Scott-B07421
   Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
   Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
   state and altivec idle
  
  
  
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, October 19, 2013 3:22 AM
To: Wang Dongsheng-B40534
Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for
pw20 state and altivec idle
   
On Thu, 2013-10-17 at 22:02 -0500, Wang Dongsheng-B40534
 wrote:

  -Original Message-
  From: Bhushan Bharat-R65777
  Sent: Thursday, October 17, 2013 2:46 PM
  To: Wang Dongsheng-B40534; Wood Scott-B07421
  Cc: linuxppc-dev@lists.ozlabs.org
  Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs
  for
  pw20 state and altivec idle
 
 
 
 -Original Message-
 From: Wang Dongsheng-B40534
 Sent: Thursday, October 17, 2013 11:22 AM
 To: Bhushan Bharat-R65777; Wood Scott-B07421
 Cc: linuxppc-dev@lists.ozlabs.org
 Subject: RE: [PATCH v5 4/4] powerpc/85xx: add
 sysfs for
 pw20 state and altivec idle



  -Original Message-
  From: Bhushan Bharat-R65777
  Sent: Thursday, October 17, 2013 11:20 AM
  To: Wang Dongsheng-B40534; Wood Scott-B07421
  Cc: linuxppc-dev@lists.ozlabs.org
  Subject: RE: [PATCH v5 4/4] powerpc/85xx: add
  sysfs for
  pw20 state and altivec idle
 
 
 
   -Original Message-
   From: Wang Dongsheng-B40534
   Sent: Thursday, October 17, 2013 8:16 AM
   To: Bhushan Bharat-R65777; Wood Scott-B07421
   Cc: linuxppc-dev@lists.ozlabs.org
   Subject: RE: [PATCH v5 4/4] powerpc/85xx:
   add sysfs for
   pw20 state and altivec idle
  
  
  
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 1:01 AM
To: Wang Dongsheng-B40534; Wood
Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx:
add sysfs for
pw20 state and altivec idle
   
   
   
 -Original Message-
 From: Wang Dongsheng-B40534
 Sent: Tuesday, October 15, 2013 2:51 PM
 To: Wood Scott-B07421
 Cc: Bhushan Bharat-R65777;
 linuxppc-dev@lists.ozlabs.org; Wang
Dongsheng-B40534
 Subject: [PATCH v5 4/4] powerpc/85xx:
 add sysfs for
 pw20 state and
altivec idle

 From: Wang Dongsheng
 dongsheng.w...@freescale.com

 Add a sys interface to enable/diable
 pw20 state or altivec idle, and
control the
 wait entry time.

 Enable/Disable interface:
 0, 

[PATCH 1/3] powerpc/p1010rdb:add P1010RDB-PB platform support

2013-11-06 Thread Zhao Qiang
The P1010RDB-PB is similar to P1010RDB(P1010RDB-PA).
So, P1010RDB-PB use the same platform file as P1010RDB.
Then Add support for P1010RDB-PB platform.

Signed-off-by: Zhao Qiang b45...@freescale.com
---
 arch/powerpc/platforms/85xx/p1010rdb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c 
b/arch/powerpc/platforms/85xx/p1010rdb.c
index 0252961..d6a3dd3 100644
--- a/arch/powerpc/platforms/85xx/p1010rdb.c
+++ b/arch/powerpc/platforms/85xx/p1010rdb.c
@@ -66,6 +66,8 @@ static int __init p1010_rdb_probe(void)
 
if (of_flat_dt_is_compatible(root, fsl,P1010RDB))
return 1;
+   if (of_flat_dt_is_compatible(root, fsl,P1010RDB-PB))
+   return 1;
return 0;
 }
 
-- 
1.8.4


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 3/3] powerpc/p1010rdb:update mtd of nand to adapt to both old and new p1010rdb

2013-11-06 Thread Zhao Qiang
P1010rdb-pa and p1010rdb-pb have different mtd of nand.
So update dts to adapt to both p1010rdb-pa and p1010rdb-pb.

Move the nand-mtd from p1010rdb.dtsi to p1010rdb-pa*.dts.
Remove nand-mtd for p1010rdb-pb, whick will use mtdparts
from u-boot instead of nand-mtd in device tree.

Signed-off-by: Zhao Qiang b45...@freescale.com
---
 arch/powerpc/boot/dts/p1010rdb-pa.dts | 14 +
 arch/powerpc/boot/dts/p1010rdb-pa.dtsi| 85 +++
 arch/powerpc/boot/dts/p1010rdb-pa_36b.dts | 14 +
 arch/powerpc/boot/dts/p1010rdb.dtsi   | 40 +--
 4 files changed, 88 insertions(+), 65 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p1010rdb-pa.dtsi

diff --git a/arch/powerpc/boot/dts/p1010rdb-pa.dts 
b/arch/powerpc/boot/dts/p1010rdb-pa.dts
index 8a74700..767d4c0 100644
--- a/arch/powerpc/boot/dts/p1010rdb-pa.dts
+++ b/arch/powerpc/boot/dts/p1010rdb-pa.dts
@@ -19,17 +19,5 @@
 };
 
 /include/ p1010rdb.dtsi
-
-phy0 {
-   interrupts = 3 1 0 0;
-};
-
-phy1 {
-   interrupts = 2 1 0 0;
-};
-
-phy2 {
-   interrupts = 2 1 0 0;
-};
-
+/include/ p1010rdb-pa.dtsi
 /include/ fsl/p1010si-post.dtsi
diff --git a/arch/powerpc/boot/dts/p1010rdb-pa.dtsi 
b/arch/powerpc/boot/dts/p1010rdb-pa.dtsi
new file mode 100644
index 000..4c5a7bf
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1010rdb-pa.dtsi
@@ -0,0 +1,85 @@
+/*
+ * P1010 RDB Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * Copyright 2013 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.
+ */
+
+ifc_nand {
+   partition@0 {
+   /* This location must not be altered  */
+   /* 1MB for u-boot Bootloader Image */
+   reg = 0x0 0x0010;
+   label = NAND U-Boot Image;
+   read-only;
+   };
+
+   partition@10 {
+   /* 1MB for DTB Image */
+   reg = 0x0010 0x0010;
+   label = NAND DTB Image;
+   };
+
+   partition@20 {
+   /* 4MB for Linux Kernel Image */
+   reg = 0x0020 0x0040;
+   label = NAND Linux Kernel Image;
+   };
+
+   partition@60 {
+   /* 4MB for Compressed Root file System Image */
+   reg = 0x0060 0x0040;
+   label = NAND Compressed RFS Image;
+   };
+
+   partition@a0 {
+   /* 15MB for JFFS2 based Root file System */
+   reg = 0x00a0 0x00f0;
+   label = NAND JFFS2 Root File System;
+   };
+
+   partition@190 {
+   /* 7MB for User Area */
+   reg = 0x0190 0x0070;
+   label = NAND User area;
+   };
+};
+
+phy0 {
+   interrupts = 3 1 0 0;
+};
+
+phy1 {
+   interrupts = 2 1 0 0;
+};
+
+phy2 {
+   interrupts = 2 1 0 0;
+};
diff --git a/arch/powerpc/boot/dts/p1010rdb-pa_36b.dts 
b/arch/powerpc/boot/dts/p1010rdb-pa_36b.dts
index 2004ee7..3033371 100644
--- a/arch/powerpc/boot/dts/p1010rdb-pa_36b.dts
+++ b/arch/powerpc/boot/dts/p1010rdb-pa_36b.dts
@@ -42,17 +42,5 @@
 };
 
 /include/ p1010rdb.dtsi
-
-phy0 {
-   interrupts = 3 1 0 0;
-};
-
-phy1 {
-   interrupts = 2 1 0 0;
-};
-
-phy2 {
-   interrupts = 2 1 0 0;
-};
-

[PATCH 2/3] powerpc/p1010rdb:update dts to adapt to both old and new p1010rdb

2013-11-06 Thread Zhao Qiang
P1010rdb-pa and p1010rdb-pb have different phy interrupts.
So update dts to adapt to both p1010rdb-pa and p1010rdb-pb.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
Signed-off-by: Zhao Qiang b45...@freescale.com
---
 arch/powerpc/boot/dts/p1010rdb-pa.dts | 35 
 arch/powerpc/boot/dts/p1010rdb-pa_36b.dts | 58 
 arch/powerpc/boot/dts/p1010rdb-pb.dts | 35 
 arch/powerpc/boot/dts/p1010rdb-pb_36b.dts | 58 
 arch/powerpc/boot/dts/p1010rdb.dts| 66 ---
 arch/powerpc/boot/dts/p1010rdb.dtsi   |  3 --
 arch/powerpc/boot/dts/p1010rdb_32b.dtsi   | 79 +++
 arch/powerpc/boot/dts/p1010rdb_36b.dts| 89 ---
 arch/powerpc/boot/dts/p1010rdb_36b.dtsi   | 79 +++
 9 files changed, 344 insertions(+), 158 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p1010rdb-pa.dts
 create mode 100644 arch/powerpc/boot/dts/p1010rdb-pa_36b.dts
 create mode 100644 arch/powerpc/boot/dts/p1010rdb-pb.dts
 create mode 100644 arch/powerpc/boot/dts/p1010rdb-pb_36b.dts
 delete mode 100644 arch/powerpc/boot/dts/p1010rdb.dts
 create mode 100644 arch/powerpc/boot/dts/p1010rdb_32b.dtsi
 delete mode 100644 arch/powerpc/boot/dts/p1010rdb_36b.dts
 create mode 100644 arch/powerpc/boot/dts/p1010rdb_36b.dtsi

diff --git a/arch/powerpc/boot/dts/p1010rdb-pa.dts 
b/arch/powerpc/boot/dts/p1010rdb-pa.dts
new file mode 100644
index 000..8a74700
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1010rdb-pa.dts
@@ -0,0 +1,35 @@
+/*
+ * P1010 RDB Device Tree Source
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * 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/ fsl/p1010si-pre.dtsi
+
+/ {
+   model = fsl,P1010RDB;
+   compatible = fsl,P1010RDB;
+
+   /include/ p1010rdb_32b.dtsi
+};
+
+/include/ p1010rdb.dtsi
+
+phy0 {
+   interrupts = 3 1 0 0;
+};
+
+phy1 {
+   interrupts = 2 1 0 0;
+};
+
+phy2 {
+   interrupts = 2 1 0 0;
+};
+
+/include/ fsl/p1010si-post.dtsi
diff --git a/arch/powerpc/boot/dts/p1010rdb-pa_36b.dts 
b/arch/powerpc/boot/dts/p1010rdb-pa_36b.dts
new file mode 100644
index 000..2004ee7
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1010rdb-pa_36b.dts
@@ -0,0 +1,58 @@
+/*
+ * P1010 RDB Device Tree Source (36-bit address map)
+ *
+ * Copyright 2011 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.
+ */
+
+/include/ fsl/p1010si-pre.dtsi
+
+/ {
+   model = fsl,P1010RDB;
+   compatible = fsl,P1010RDB;
+
+   /include/ p1010rdb_36b.dtsi
+};
+
+/include/ p1010rdb.dtsi
+
+phy0 {
+   interrupts = 3 1 0 0;
+};
+
+phy1 {
+   interrupts = 2 1 0 0;
+};
+
+phy2 {
+   interrupts = 2 1 0 0;
+};
+
+/include/ fsl/p1010si-post.dtsi
diff --git a/arch/powerpc/boot/dts/p1010rdb-pb.dts 
b/arch/powerpc/boot/dts/p1010rdb-pb.dts
new file mode 100644
index 000..6eeb7d3
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1010rdb-pb.dts
@@ -0,0 +1,35 @@
+/*
+ * P1010 RDB Device Tree Source
+ *
+ * 

Re: [PATCH 4/7] IBM Akebono: Add support to the OHCI platform driver for Akebono

2013-11-06 Thread Alistair Popple
On Tue, 5 Nov 2013 10:04:02 Alan Stern wrote:

[snip]

  
  +   /* Platforms using DT don't always provide platform data.
  +* This should provide reasonable defaults. */
 
   /*
* The accepted format for multi-line
* comments is like this.
*/
 

Ok, I'll fix that for the next revision.

  +   if (!pdata)
  +   dev-dev.platform_data = pdata = ohci_platform_defaults;
  +
  
  irq = platform_get_irq(dev, 0);
  if (irq  0) {
  
  dev_err(dev-dev, no irq provided);
  
  @@ -171,6 +175,11 @@ static int ohci_platform_resume(struct device *dev)
  
   #define ohci_platform_resume   NULL
   #endif /* CONFIG_PM */
  
  +static const struct of_device_id ohci_of_match[] = {
  +   { .compatible = ibm,akebono-ohci, },
  +   {},
  +};
  +
  
   static const struct platform_device_id ohci_platform_table[] = {
   
  { ohci-platform, 0 },
  { }
  
  @@ -191,6 +200,7 @@ static struct platform_driver ohci_platform_driver = {
  
  .owner  = THIS_MODULE,
  .name   = ohci-platform,
  .pm = ohci_platform_pm_ops,
  
  +   .of_match_table = ohci_of_match,
  
  }
   
   };
 
 Update the comment formatting, and then you can resubmit with
 
 Acked-by: Alan Stern st...@rowland.harvard.edu

Thanks. Based on the discussion for the EHCI driver I would like to change the 
compatibility string to usb-ochi (instead of ibm,akebono-ohci). Are you 
still happy for me to add the Acked-by with the alternate compatibility (and 
of course the formatting fix)? No other drivers currently use usb-ochi so it 
shouldn't require any merging of drivers.

Regards,

Alistair

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH V7 5/7] POWER/cpuidle: Generic POWER CPUIDLE driver supporting PSERIES.

2013-11-06 Thread Deepthi Dharwar
On 11/07/2013 02:35 AM, Daniel Lezcano wrote:
 On 10/29/2013 12:01 PM, Deepthi Dharwar wrote:
 This patch includes cleanup and refactoring of the
 existing code to make the driver POWER generic.
 * Re-naming the functions from pseries to generic power.
 * Re-naming the backend driver from pseries_idle to
ibm-power-idle.

 Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
 
 Acked-by: Daniel Lezcano daniel.lezc...@linaro.org

Hi Daniel,

Thanks for the Acks.

 ... but I am wondering if 'power' name is not confusing with power
 management and if 'powerpc' would suit better.

'powerpc' would be very generic arch and would comprise of all platforms
including embedded 32/64 bit to server 64 bit (similar to that of ARM).
This driver does not intend to support complete powerpc arch, but just
PSERIES and POWERNV platforms termed as 'POWER' processors. So to avoid
confusion btw 'power mgmt' and 'POWER' archs, I have prefixed both the
driver and file names with 'IBM'namely ibm-power-driver, cpuidle-ibm-power.

Regards,
Deepthi

 ---
   drivers/cpuidle/cpuidle-ibm-power.c |   32
 
   1 file changed, 16 insertions(+), 16 deletions(-)

 diff --git a/drivers/cpuidle/cpuidle-ibm-power.c
 b/drivers/cpuidle/cpuidle-ibm-power.c
 index e81c207..5b92242 100644
 --- a/drivers/cpuidle/cpuidle-ibm-power.c
 +++ b/drivers/cpuidle/cpuidle-ibm-power.c
 @@ -20,8 +20,8 @@
   #include asm/runlatch.h
   #include asm/plpar_wrappers.h

 -struct cpuidle_driver pseries_idle_driver = {
 -.name = pseries_idle,
 +struct cpuidle_driver power_idle_driver = {
 +.name = ibm_power_idle,
   .owner= THIS_MODULE,
   };

 @@ -182,7 +182,7 @@ void update_smt_snooze_delay(int cpu, int residency)
   drv-states[1].target_residency = residency;
   }

 -static int pseries_cpuidle_add_cpu_notifier(struct notifier_block *n,
 +static int power_cpuidle_add_cpu_notifier(struct notifier_block *n,
   unsigned long action, void *hcpu)
   {
   int hotcpu = (unsigned long)hcpu;
 @@ -213,16 +213,16 @@ static int
 pseries_cpuidle_add_cpu_notifier(struct notifier_block *n,
   }

   static struct notifier_block setup_hotplug_notifier = {
 -.notifier_call = pseries_cpuidle_add_cpu_notifier,
 +.notifier_call = power_cpuidle_add_cpu_notifier,
   };

   /*
 - * pseries_cpuidle_driver_init()
 + * power_cpuidle_driver_init()
*/
 -static int pseries_cpuidle_driver_init(void)
 +static int power_cpuidle_driver_init(void)
   {
   int idle_state;
 -struct cpuidle_driver *drv = pseries_idle_driver;
 +struct cpuidle_driver *drv = power_idle_driver;

   drv-state_count = 0;
   for (idle_state = 0; idle_state  max_idle_state; ++idle_state) {
 @@ -241,10 +241,10 @@ static int pseries_cpuidle_driver_init(void)
   }

   /*
 - * pseries_idle_probe()
 + * power_idle_probe()
* Choose state table for shared versus dedicated partition
*/
 -static int pseries_idle_probe(void)
 +static int power_idle_probe(void)
   {

   if (cpuidle_disable != IDLE_NO_OVERRIDE)
 @@ -264,24 +264,24 @@ static int pseries_idle_probe(void)
   return 0;
   }

 -static int __init pseries_processor_idle_init(void)
 +static int __init power_processor_idle_init(void)
   {
   int retval;

 -retval = pseries_idle_probe();
 +retval = power_idle_probe();
   if (retval)
   return retval;

 -pseries_cpuidle_driver_init();
 -retval = cpuidle_register(pseries_idle_driver, NULL);
 +power_cpuidle_driver_init();
 +retval = cpuidle_register(power_idle_driver, NULL);
   if (retval) {
 -printk(KERN_DEBUG Registration of pseries driver failed.\n);
 +printk(KERN_DEBUG Registration of ibm_power_idle driver
 failed.\n);
   return retval;
   }

   register_cpu_notifier(setup_hotplug_notifier);
 -printk(KERN_DEBUG pseries_idle_driver registered\n);
 +printk(KERN_DEBUG ibm_power_idle registered\n);
   return 0;
   }

 -device_initcall(pseries_processor_idle_init);
 +device_initcall(power_processor_idle_init);

 
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 4/7] IBM Akebono: Add support to the OHCI platform driver for Akebono

2013-11-06 Thread Benjamin Herrenschmidt
On Thu, 2013-11-07 at 14:34 +1100, Alistair Popple wrote:
 Thanks. Based on the discussion for the EHCI driver I would like to change 
 the 
 compatibility string to usb-ochi (instead of ibm,akebono-ohci). Are you 
 still happy for me to add the Acked-by with the alternate compatibility (and 
 of course the formatting fix)? No other drivers currently use usb-ochi so 
 it 
 shouldn't require any merging of drivers.

s/ochi/ohci/ :-)

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH V7 5/7] POWER/cpuidle: Generic POWER CPUIDLE driver supporting PSERIES.

2013-11-06 Thread Benjamin Herrenschmidt
On Thu, 2013-11-07 at 09:45 +0530, Deepthi Dharwar wrote:
 'powerpc' would be very generic arch and would comprise of all platforms
 including embedded 32/64 bit to server 64 bit (similar to that of ARM).
 This driver does not intend to support complete powerpc arch, but just
 PSERIES and POWERNV platforms termed as 'POWER' processors. So to avoid
 confusion btw 'power mgmt' and 'POWER' archs, I have prefixed both the
 driver and file names with 'IBM'namely ibm-power-driver, cpuidle-ibm-power.

Why not book3s ? powerpc-book3s ?

That's what we use in other places to differenciate between the families

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH V7 5/7] POWER/cpuidle: Generic POWER CPUIDLE driver supporting PSERIES.

2013-11-06 Thread Deepthi Dharwar
On 11/07/2013 10:31 AM, Benjamin Herrenschmidt wrote:
 On Thu, 2013-11-07 at 09:45 +0530, Deepthi Dharwar wrote:
 'powerpc' would be very generic arch and would comprise of all platforms
 including embedded 32/64 bit to server 64 bit (similar to that of ARM).
 This driver does not intend to support complete powerpc arch, but just
 PSERIES and POWERNV platforms termed as 'POWER' processors. So to avoid
 confusion btw 'power mgmt' and 'POWER' archs, I have prefixed both the
 driver and file names with 'IBM'namely ibm-power-driver, cpuidle-ibm-power.
 

Hi Ben,

 Why not book3s ? powerpc-book3s ?

I went with 'ibm-power' thinking it would resolve the confusion,
but if ppl feel that is is good to get away from 'POWER' and have
powerpc-book3s instead to make things clearer, I am open for it.


Regards,
Deepthi

 That's what we use in other places to differenciate between the families
 
 Ben.
 
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v2 1/2] powerpc/kvm: fix rare but potential deadlock scene

2013-11-06 Thread Liu Ping Fan
Since kvmppc_hv_find_lock_hpte() is called from both virtmode and
realmode, so it can trigger the deadlock.

Suppose the following scene:

Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of vcpus.

If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is switched out,
and on cpuN, vcpu_A_2 try to lock X in realmode, then cpuN will be caught in
realmode for a long time.

What makes things even worse if the following happens,
  On cpuM, bitlockX is hold, on cpuN, Y is hold.
  vcpu_B_2 try to lock Y on cpuM in realmode
  vcpu_A_2 try to lock X on cpuN in realmode

Oops! deadlock happens

Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
---
 arch/powerpc/kvm/book3s_64_mmu_hv.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 043eec8..dbc1478 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -474,10 +474,13 @@ static int kvmppc_mmu_book3s_64_hv_xlate(struct kvm_vcpu 
*vcpu, gva_t eaddr,
}
 
/* Find the HPTE in the hash table */
+   preempt_disable();
index = kvmppc_hv_find_lock_hpte(kvm, eaddr, slb_v,
 HPTE_V_VALID | HPTE_V_ABSENT);
-   if (index  0)
+   if (index  0) {
+   preempt_enable();
return -ENOENT;
+   }
hptep = (unsigned long *)(kvm-arch.hpt_virt + (index  4));
v = hptep[0]  ~HPTE_V_HVLOCK;
gr = kvm-arch.revmap[index].guest_rpte;
@@ -485,6 +488,7 @@ static int kvmppc_mmu_book3s_64_hv_xlate(struct kvm_vcpu 
*vcpu, gva_t eaddr,
/* Unlock the HPTE */
asm volatile(lwsync : : : memory);
hptep[0] = v;
+   preempt_enable();
 
gpte-eaddr = eaddr;
gpte-vpage = ((v  HPTE_V_AVPN)  4) | ((eaddr  12)  0xfff);
-- 
1.8.1.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v2 2/2] powerpc/kvm: remove redundant assignment

2013-11-06 Thread Liu Ping Fan
ret is assigned twice with the same value, so remove the later one.

Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
Acked-by: Paul Mackerras pau...@samba.org
---
 arch/powerpc/kvm/book3s_64_mmu_hv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index dbc1478..9b97b42 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -733,7 +733,6 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run, struct 
kvm_vcpu *vcpu,
lock_rmap(rmap);
 
/* Check if we might have been invalidated; let the guest retry if so */
-   ret = RESUME_GUEST;
if (mmu_notifier_retry(vcpu-kvm, mmu_seq)) {
unlock_rmap(rmap);
goto out_unlock;
-- 
1.8.1.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] powerpc/85xx: don't init the mpic ipi for the SoC which has doorbell support

2013-11-06 Thread Kevin Hao
It makes no sense to initialize the mpic ipi for the SoC which has
doorbell support. So set the smp_85xx_ops.probe to NULL for this
case. Since the smp_85xx_ops.probe is also used in function
smp_85xx_setup_cpu() to check if we need to invoke
mpic_setup_this_cpu(), we introduce a new setup_cpu function
smp_85xx_basic_setup() to remove this dependency.

Signed-off-by: Kevin Hao haoke...@gmail.com
---

Boot test on p2020rdb and p5020ds.

 arch/powerpc/platforms/85xx/smp.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/smp.c 
b/arch/powerpc/platforms/85xx/smp.c
index 281b7f01df63..d3b310f87ce9 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -388,15 +388,18 @@ static void mpc85xx_smp_machine_kexec(struct kimage 
*image)
 }
 #endif /* CONFIG_KEXEC */
 
-static void smp_85xx_setup_cpu(int cpu_nr)
+static void smp_85xx_basic_setup(int cpu_nr)
 {
-   if (smp_85xx_ops.probe == smp_mpic_probe)
-   mpic_setup_this_cpu();
-
if (cpu_has_feature(CPU_FTR_DBELL))
doorbell_setup_this_cpu();
 }
 
+static void smp_85xx_setup_cpu(int cpu_nr)
+{
+   mpic_setup_this_cpu();
+   smp_85xx_basic_setup(cpu_nr);
+}
+
 static const struct of_device_id mpc85xx_smp_guts_ids[] = {
{ .compatible = fsl,mpc8572-guts, },
{ .compatible = fsl,p1020-guts, },
@@ -411,13 +414,14 @@ void __init mpc85xx_smp_init(void)
 {
struct device_node *np;
 
-   smp_85xx_ops.setup_cpu = smp_85xx_setup_cpu;
 
np = of_find_node_by_type(NULL, open-pic);
if (np) {
smp_85xx_ops.probe = smp_mpic_probe;
+   smp_85xx_ops.setup_cpu = smp_85xx_setup_cpu;
smp_85xx_ops.message_pass = smp_mpic_message_pass;
-   }
+   } else
+   smp_85xx_ops.setup_cpu = smp_85xx_basic_setup;
 
if (cpu_has_feature(CPU_FTR_DBELL)) {
/*
@@ -426,6 +430,7 @@ void __init mpc85xx_smp_init(void)
 */
smp_85xx_ops.message_pass = NULL;
smp_85xx_ops.cause_ipi = doorbell_cause_ipi;
+   smp_85xx_ops.probe = NULL;
}
 
np = of_find_matching_node(NULL, mpc85xx_smp_guts_ids);
-- 
1.8.3.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 3/3] powerpc/kvm: remove redundant assignment

2013-11-06 Thread Alexander Graf

Am 06.11.2013 um 20:58 schrieb Benjamin Herrenschmidt 
b...@kernel.crashing.org:

 On Wed, 2013-11-06 at 12:24 +0100, Alexander Graf wrote:
 On 05.11.2013, at 08:42, Liu Ping Fan kernelf...@gmail.com wrote:
 
 Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
 
 Patch description missing.
 
 Do you really need a description for trivial one-lines whose subject
 is a perfectly complete description already ?

Would I ask for it otherwise? It's also not 100% obvious that the assignment is 
redundant.


Alex

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 3/3] powerpc/kvm: remove redundant assignment

2013-11-06 Thread Benjamin Herrenschmidt
On Thu, 2013-11-07 at 08:52 +0100, Alexander Graf wrote:
 Am 06.11.2013 um 20:58 schrieb Benjamin Herrenschmidt 
 b...@kernel.crashing.org:
 
  On Wed, 2013-11-06 at 12:24 +0100, Alexander Graf wrote:
  On 05.11.2013, at 08:42, Liu Ping Fan kernelf...@gmail.com wrote:
  
  Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
  
  Patch description missing.
  
  Do you really need a description for trivial one-lines whose subject
  is a perfectly complete description already ?
 
 Would I ask for it otherwise? It's also not 100% obvious that the assignment 
 is redundant.

And ? An explanation isn't going to be clearer than the code in that
case ...

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev