[PATCH] powerpc: Correct FSCR bit definitions

2013-09-05 Thread Paul Mackerras 
Commit 74e400cee6 (powerpc: Rework setting up H/FSCR bit definitions)
ended up with incorrect bit numbers for FSCR_PM_LG and FSCR_BHRB_LG.
This fixes them.

Signed-off-by: Paul Mackerras pau...@samba.org
---
 arch/powerpc/include/asm/reg.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index dc10bf5..10d1ef0 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -258,8 +258,8 @@
 #define FSCR_TAR_LG8   /* Enable Target Address Register */
 #define FSCR_EBB_LG7   /* Enable Event Based Branching */
 #define FSCR_TM_LG 5   /* Enable Transactional Memory */
-#define FSCR_PM_LG 4   /* Enable prob/priv access to PMU SPRs */
-#define FSCR_BHRB_LG   3   /* Enable Branch History Rolling Buffer*/
+#define FSCR_BHRB_LG   4   /* Enable Branch History Rolling Buffer*/
+#define FSCR_PM_LG 3   /* Enable prob/priv access to PMU SPRs */
 #define FSCR_DSCR_LG   2   /* Enable Data Stream Control Register */
 #define FSCR_VECVSX_LG 1   /* Enable VMX/VSX  */
 #define FSCR_FP_LG 0   /* Enable Floating Point */
-- 
1.8.4.rc3

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

Re: [PATCH] powerpc: Correct FSCR bit definitions

2013-09-05 Thread Michael Neuling 
Paul Mackerras pau...@samba.org wrote:

 Commit 74e400cee6 (powerpc: Rework setting up H/FSCR bit definitions)
 ended up with incorrect bit numbers for FSCR_PM_LG and FSCR_BHRB_LG.
 This fixes them.
 
 Signed-off-by: Paul Mackerras pau...@samba.org

Acked-by: Michael Neuling mi...@neuling.org

Sorry about that screw up.

Mikey

 ---
  arch/powerpc/include/asm/reg.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
 index dc10bf5..10d1ef0 100644
 --- a/arch/powerpc/include/asm/reg.h
 +++ b/arch/powerpc/include/asm/reg.h
 @@ -258,8 +258,8 @@
  #define FSCR_TAR_LG  8   /* Enable Target Address Register */
  #define FSCR_EBB_LG  7   /* Enable Event Based Branching */
  #define FSCR_TM_LG   5   /* Enable Transactional Memory */
 -#define FSCR_PM_LG   4   /* Enable prob/priv access to PMU SPRs */
 -#define FSCR_BHRB_LG 3   /* Enable Branch History Rolling Buffer*/
 +#define FSCR_BHRB_LG 4   /* Enable Branch History Rolling Buffer*/
 +#define FSCR_PM_LG   3   /* Enable prob/priv access to PMU SPRs */
  #define FSCR_DSCR_LG 2   /* Enable Data Stream Control Register */
  #define FSCR_VECVSX_LG   1   /* Enable VMX/VSX  */
  #define FSCR_FP_LG   0   /* Enable Floating Point */
 -- 
 1.8.4.rc3
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Please pull 'next' branch of 5xxx tree

2013-09-05 Thread Benjamin Herrenschmidt 
On Tue, 2013-09-03 at 22:39 +0200, Anatolij Gustschin wrote:
 Hi Ben !
 
 Please pull mpc5xxx patches for v3.12.
 
 There are cleanups for some mpc5121 specific drivers and DTS files
 in preparation to switch mpc5121 clock support to a clock driver
 based on common clock framework. Additionally Sebastian fixed the
 mpc52xx PIC driver so that it builds when using older gcc versions.
 
 All these patches have already been in linux-next for a while.

Thanks. BTW. Next time, any chance you can base this off the same point
in Linus tree where my next branch is based  ? Or base of my next
branch :-)

It makes the merged a lot cleaner

Cheers,
Ben.

 Thanks,
 
 Anatolij
 
 
 The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8:
 
   Linux 3.11-rc5 (2013-08-11 18:04:20 -0700)
 
 are available in the git repository at:
 
   git://git.denx.de/linux-2.6-agust.git next
 
 for you to fetch changes up to f2110cb961200e5c382e9d0878ded015109b5dd6:
 
   dts: mpc512x: prepare for preprocessor support (2013-08-24 00:18:55 +0200)
 
 
 Gerhard Sittig (6):
   serial: mpc512x: cleanup clock API use
   USB: fsl-mph-dr-of: cleanup clock API use
   mtd: mpc5121_nfc: cleanup clock API use
   fsl-viu: cleanup clock API use
   powerpc: mpc512x: array decl for MCLK registers in CCM
   dts: mpc512x: prepare for preprocessor support
 
 Sebastian Siewior (1):
   powerpc: 52xx: provide a default in mpc52xx_irqhost_map()
 
  arch/powerpc/boot/dts/ac14xx.dts  |2 +-
  arch/powerpc/boot/dts/include/dt-bindings |1 +
  arch/powerpc/boot/dts/mpc5121ads.dts  |2 +-
  arch/powerpc/boot/dts/pdm360ng.dts|2 +-
  arch/powerpc/include/asm/mpc5121.h|   18 +-
  arch/powerpc/platforms/52xx/mpc52xx_pic.c |3 +-
  drivers/media/platform/fsl-viu.c  |   23 ---
  drivers/mtd/nand/mpc5121_nfc.c|   21 ---
  drivers/tty/serial/mpc52xx_uart.c |   98 
 -
  drivers/usb/host/fsl-mph-dr-of.c  |   16 ++---
  10 files changed, 123 insertions(+), 63 deletions(-)
  create mode 12 arch/powerpc/boot/dts/include/dt-bindings


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

[PATCH] powerpc: Fix possible deadlock on page fault

2013-09-05 Thread Aneesh Kumar K.V 
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com

 stack_grow_into/14082 is trying to acquire lock:
  (mm-mmap_sem){++}, at: [c0206d28] .might_fault+0x78/0xe0

 but task is already holding lock:
  (mm-mmap_sem){++}, at: [c07ffd8c] .do_page_fault+0x24c/0x910

 other info that might help us debug this:
  Possible unsafe locking scenario:

CPU0

   lock(mm-mmap_sem);
   lock(mm-mmap_sem);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 1 lock held by stack_grow_into/14082:
  #0:  (mm-mmap_sem){++}, at: [c07ffd8c] 
.do_page_fault+0x24c/0x910

 stack backtrace:
 CPU: 21 PID: 14082 Comm: stack_grow_into Not tainted 3.10.0-10.el7.ppc64.debug 
#1
 Call Trace:
 [c003d396b850] [c0016e7c] .show_stack+0x7c/0x1f0 (unreliable)
 [c003d396b920] [c0813fc8] .dump_stack+0x28/0x3c
 [c003d396b990] [c0124b90] .__lock_acquire+0x1640/0x1800
 [c003d396bab0] [c012570c] .lock_acquire+0xac/0x250
 [c003d396bb80] [c0206d54] .might_fault+0xa4/0xe0
 [c003d396bbf0] [c07ffe2c] .do_page_fault+0x2ec/0x910
 [c003d396be30] [c00092e8] handle_page_fault+0x10/0x30

Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
 arch/powerpc/mm/fault.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 8726779..dc2902a 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -206,7 +206,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned 
long address,
int trap = TRAP(regs);
int is_exec = trap == 0x400;
int fault;
-   int rc = 0;
+   int rc = 0, store_update;
 
 #if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
/*
@@ -280,6 +280,13 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned 
long address,
 
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
 
+   /*
+* We want to do this outside mmap_sem, because reading code around nip
+* can result in fault, which will cause a deadlock when called with
+* mmap_sem held
+*/
+   store_update = store_updates_sp(regs);
+
/* When running in the kernel we expect faults to occur only to
 * addresses in user space.  All other faults represent errors in the
 * kernel and should generate an OOPS.  Unfortunately, in the case of an
@@ -346,7 +353,7 @@ retry:
 * expand the stack rather than segfaulting.
 */
if (address + 2048  uregs-gpr[1]
-(!user_mode(regs) || !store_updates_sp(regs)))
+(!user_mode(regs) || !store_update))
goto bad_area;
}
if (expand_stack(vma, address))
-- 
1.8.1.2

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

[PATCH v2 3/6] powerpc/pci: use pci_is_pcie() to simplify code

2013-09-05 Thread Yijing Wang 
Use pci_is_pcie() to simplify code.

Acked-by: Kumar Gala ga...@kernel.crashing.org
Reviewed-by: Gavin Shan sha...@linux.vnet.ibm.com
Signed-off-by: Yijing Wang wangyij...@huawei.com
Cc: Gavin Shan sha...@linux.vnet.ibm.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
 arch/powerpc/kernel/eeh.c |3 +--
 arch/powerpc/sysdev/fsl_pci.c |2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 55593ee..6ebbe54 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -189,8 +189,7 @@ static size_t eeh_gather_pci_data(struct eeh_dev *edev, 
char * buf, size_t len)
}
 
/* If PCI-E capable, dump PCI-E cap 10, and the AER */
-   cap = pci_find_capability(dev, PCI_CAP_ID_EXP);
-   if (cap) {
+   if (pci_is_pcie(dev)) {
n += scnprintf(buf+n, len-n, pci-e cap10:\n);
printk(KERN_WARNING
   EEH: PCI-E capabilities and status follow:\n);
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 46ac1dd..5402a1d 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -41,7 +41,7 @@ static void quirk_fsl_pcie_header(struct pci_dev *dev)
u8 hdr_type;
 
/* if we aren't a PCIe don't bother */
-   if (!pci_find_capability(dev, PCI_CAP_ID_EXP))
+   if (!pci_is_pcie(dev))
return;
 
/* if we aren't in host mode don't bother */
-- 
1.7.1


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

Re: [PATCH] powerpc: Fix possible deadlock on page fault

2013-09-05 Thread Paul Mackerras 
On Thu, Sep 05, 2013 at 12:47:02PM +0530, Aneesh Kumar K.V wrote:

 @@ -280,6 +280,13 @@ int __kprobes do_page_fault(struct pt_regs *regs, 
 unsigned long address,
  
   perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
  
 + /*
 +  * We want to do this outside mmap_sem, because reading code around nip
 +  * can result in fault, which will cause a deadlock when called with
 +  * mmap_sem held
 +  */
 + store_update = store_updates_sp(regs);

We should only call store_updates_sp() if user_mode(regs); that was
the previous behaviour.

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

Re: [PATCH] powerpc: Fix possible deadlock on page fault

2013-09-05 Thread Aneesh Kumar K.V 
Paul Mackerras pau...@samba.org writes:

 On Thu, Sep 05, 2013 at 12:47:02PM +0530, Aneesh Kumar K.V wrote:

 @@ -280,6 +280,13 @@ int __kprobes do_page_fault(struct pt_regs *regs, 
 unsigned long address,
  
  perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
  
 +/*
 + * We want to do this outside mmap_sem, because reading code around nip
 + * can result in fault, which will cause a deadlock when called with
 + * mmap_sem held
 + */
 +store_update = store_updates_sp(regs);

 We should only call store_updates_sp() if user_mode(regs); that was
 the previous behaviour.

Updated to 

diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 8726779..fad7af6 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -206,7 +206,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned 
long address,
int trap = TRAP(regs);
int is_exec = trap == 0x400;
int fault;
-   int rc = 0;
+   int rc = 0, store_update = 0;
 
 #if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
/*
@@ -280,6 +280,14 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned 
long address,
 
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
 
+   /*
+* We want to do this outside mmap_sem, because reading code around nip
+* can result in fault, which will cause a deadlock when called with
+* mmap_sem held
+*/
+   if (user_mode(regs))
+   store_update = store_updates_sp(regs);
+
/* When running in the kernel we expect faults to occur only to
 * addresses in user space.  All other faults represent errors in the
 * kernel and should generate an OOPS.  Unfortunately, in the case of an
@@ -345,8 +353,7 @@ retry:
 * between the last mapped region and the stack will
 * expand the stack rather than segfaulting.
 */
-   if (address + 2048  uregs-gpr[1]
-(!user_mode(regs) || !store_updates_sp(regs)))
+   if (address + 2048  uregs-gpr[1]  !store_update)
goto bad_area;
}
if (expand_stack(vma, address))

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

[PATCH -V2] powerpc: Fix possible deadlock on page fault

2013-09-05 Thread Aneesh Kumar K.V 
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com

 stack_grow_into/14082 is trying to acquire lock:
  (mm-mmap_sem){++}, at: [c0206d28] .might_fault+0x78/0xe0

 but task is already holding lock:
  (mm-mmap_sem){++}, at: [c07ffd8c] .do_page_fault+0x24c/0x910

 other info that might help us debug this:
  Possible unsafe locking scenario:

CPU0

   lock(mm-mmap_sem);
   lock(mm-mmap_sem);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 1 lock held by stack_grow_into/14082:
  #0:  (mm-mmap_sem){++}, at: [c07ffd8c] 
.do_page_fault+0x24c/0x910

 stack backtrace:
 CPU: 21 PID: 14082 Comm: stack_grow_into Not tainted 3.10.0-10.el7.ppc64.debug 
#1
 Call Trace:
 [c003d396b850] [c0016e7c] .show_stack+0x7c/0x1f0 (unreliable)
 [c003d396b920] [c0813fc8] .dump_stack+0x28/0x3c
 [c003d396b990] [c0124b90] .__lock_acquire+0x1640/0x1800
 [c003d396bab0] [c012570c] .lock_acquire+0xac/0x250
 [c003d396bb80] [c0206d54] .might_fault+0xa4/0xe0
 [c003d396bbf0] [c07ffe2c] .do_page_fault+0x2ec/0x910
 [c003d396be30] [c00092e8] handle_page_fault+0x10/0x30

Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
 arch/powerpc/mm/fault.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 8726779..fad7af6 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -206,7 +206,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned 
long address,
int trap = TRAP(regs);
int is_exec = trap == 0x400;
int fault;
-   int rc = 0;
+   int rc = 0, store_update = 0;
 
 #if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
/*
@@ -280,6 +280,14 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned 
long address,
 
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
 
+   /*
+* We want to do this outside mmap_sem, because reading code around nip
+* can result in fault, which will cause a deadlock when called with
+* mmap_sem held
+*/
+   if (user_mode(regs))
+   store_update = store_updates_sp(regs);
+
/* When running in the kernel we expect faults to occur only to
 * addresses in user space.  All other faults represent errors in the
 * kernel and should generate an OOPS.  Unfortunately, in the case of an
@@ -345,8 +353,7 @@ retry:
 * between the last mapped region and the stack will
 * expand the stack rather than segfaulting.
 */
-   if (address + 2048  uregs-gpr[1]
-(!user_mode(regs) || !store_updates_sp(regs)))
+   if (address + 2048  uregs-gpr[1]  !store_update)
goto bad_area;
}
if (expand_stack(vma, address))
-- 
1.8.1.2

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

Re: [PATCH] powerpc: Fix possible deadlock on page fault

2013-09-05 Thread Benjamin Herrenschmidt 
On Thu, 2013-09-05 at 17:18 +0530, Aneesh Kumar K.V wrote:
 Paul Mackerras pau...@samba.org writes:
 
  On Thu, Sep 05, 2013 at 12:47:02PM +0530, Aneesh Kumar K.V wrote:
 
  @@ -280,6 +280,13 @@ int __kprobes do_page_fault(struct pt_regs *regs, 
  unsigned long address,
   
 perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
   
  +  /*
  +   * We want to do this outside mmap_sem, because reading code around nip
  +   * can result in fault, which will cause a deadlock when called with
  +   * mmap_sem held
  +   */
  +  store_update = store_updates_sp(regs);
 
  We should only call store_updates_sp() if user_mode(regs); that was
  the previous behaviour.
 
 Updated to 
 
 diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
 index 8726779..fad7af6 100644
 --- a/arch/powerpc/mm/fault.c
 +++ b/arch/powerpc/mm/fault.c
 @@ -206,7 +206,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, 
 unsigned long address,
   int trap = TRAP(regs);
   int is_exec = trap == 0x400;
   int fault;
 - int rc = 0;
 + int rc = 0, store_update = 0;

Keep the sp, in the name, it's confusing otherwise. It's not just
about store update, it's about specifically recognizing instructions
used to update the stack frame in order to let them and only them
significantly lower the stack pointer.

Cheers,
Ben.

  #if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
   /*
 @@ -280,6 +280,14 @@ int __kprobes do_page_fault(struct pt_regs *regs, 
 unsigned long address,
  
   perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
  
 + /*
 +  * We want to do this outside mmap_sem, because reading code around nip
 +  * can result in fault, which will cause a deadlock when called with
 +  * mmap_sem held
 +  */
 + if (user_mode(regs))
 + store_update = store_updates_sp(regs);
 +
   /* When running in the kernel we expect faults to occur only to
* addresses in user space.  All other faults represent errors in the
* kernel and should generate an OOPS.  Unfortunately, in the case of an
 @@ -345,8 +353,7 @@ retry:
* between the last mapped region and the stack will
* expand the stack rather than segfaulting.
*/
 - if (address + 2048  uregs-gpr[1]
 -  (!user_mode(regs) || !store_updates_sp(regs)))
 + if (address + 2048  uregs-gpr[1]  !store_update)
   goto bad_area;
   }
   if (expand_stack(vma, address))


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

Re: [PATCH] powerpc: Fix possible deadlock on page fault

2013-09-05 Thread Aneesh Kumar K.V 
Benjamin Herrenschmidt b...@kernel.crashing.org writes:

 On Thu, 2013-09-05 at 17:18 +0530, Aneesh Kumar K.V wrote:
 Paul Mackerras pau...@samba.org writes:
 
  On Thu, Sep 05, 2013 at 12:47:02PM +0530, Aneesh Kumar K.V wrote:
 
  @@ -280,6 +280,13 @@ int __kprobes do_page_fault(struct pt_regs *regs, 
  unsigned long address,
   
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
   
  + /*
  +  * We want to do this outside mmap_sem, because reading code around nip
  +  * can result in fault, which will cause a deadlock when called with
  +  * mmap_sem held
  +  */
  + store_update = store_updates_sp(regs);
 
  We should only call store_updates_sp() if user_mode(regs); that was
  the previous behaviour.
 
 Updated to 
 
 diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
 index 8726779..fad7af6 100644
 --- a/arch/powerpc/mm/fault.c
 +++ b/arch/powerpc/mm/fault.c
 @@ -206,7 +206,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, 
 unsigned long address,
  int trap = TRAP(regs);
  int is_exec = trap == 0x400;
  int fault;
 -int rc = 0;
 +int rc = 0, store_update = 0;

 Keep the sp, in the name, it's confusing otherwise. It's not just
 about store update, it's about specifically recognizing instructions
 used to update the stack frame in order to let them and only them
 significantly lower the stack pointer.


Ok will do that. I posted a v2. So will wait for other feedback before i
post a new version.

-aneesh

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

Re: [PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling

2013-09-05 Thread Gleb Natapov 
On Wed, Sep 04, 2013 at 02:01:28AM +1000, Alexey Kardashevskiy wrote:
 On 09/03/2013 08:53 PM, Gleb Natapov wrote:
  On Mon, Sep 02, 2013 at 01:14:29PM +1000, Alexey Kardashevskiy wrote:
  On 09/01/2013 10:06 PM, Gleb Natapov wrote:
  On Wed, Aug 28, 2013 at 06:50:41PM +1000, Alexey Kardashevskiy wrote:
  This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
  and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
  them to user space which saves time on switching to user space and back.
 
  Both real and virtual modes are supported. The kernel tries to
  handle a TCE request in the real mode, if fails it passes the request
  to the virtual mode to complete the operation. If it a virtual mode
  handler fails, the request is passed to user space.
 
  The first user of this is VFIO on POWER. Trampolines to the VFIO external
  user API functions are required for this patch.
 
  This adds a SPAPR TCE IOMMU KVM device to associate a logical bus
  number (LIOBN) with an VFIO IOMMU group fd and enable in-kernel handling
  of map/unmap requests. The device supports a single attribute which is
  a struct with LIOBN and IOMMU fd. When the attribute is set, the device
  establishes the connection between KVM and VFIO.
 
  Tests show that this patch increases transmission speed from 220MB/s
  to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
 
  Signed-off-by: Paul Mackerras pau...@samba.org
  Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
 
  ---
 
  Changes:
  v9:
  * KVM_CAP_SPAPR_TCE_IOMMU ioctl to KVM replaced with SPAPR TCE IOMMU
  KVM device
  * release_spapr_tce_table() is not shared between different TCE types
  * reduced the patch size by moving VFIO external API
  trampolines to separate patche
  * moved documentation from Documentation/virtual/kvm/api.txt to
  Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
 
  v8:
  * fixed warnings from check_patch.pl
 
  2013/07/11:
  * removed multiple #ifdef IOMMU_API as IOMMU_API is always enabled
  for KVM_BOOK3S_64
  * kvmppc_gpa_to_hva_and_get also returns host phys address. Not much 
  sense
  for this here but the next patch for hugepages support will use it more.
 
  2013/07/06:
  * added realmode arch_spin_lock to protect TCE table from races
  in real and virtual modes
  * POWERPC IOMMU API is changed to support real mode
  * iommu_take_ownership and iommu_release_ownership are protected by
  iommu_table's locks
  * VFIO external user API use rewritten
  * multiple small fixes
 
  2013/06/27:
  * tce_list page is referenced now in order to protect it from accident
  invalidation during H_PUT_TCE_INDIRECT execution
  * added use of the external user VFIO API
 
  2013/06/05:
  * changed capability number
  * changed ioctl number
  * update the doc article number
 
  2013/05/20:
  * removed get_user() from real mode handlers
  * kvm_vcpu_arch::tce_tmp usage extended. Now real mode handler puts there
  translated TCEs, tries realmode_get_page() on those and if it fails, it
  passes control over the virtual mode handler which tries to finish
  the request handling
  * kvmppc_lookup_pte() now does realmode_get_page() protected by BUSY bit
  on a page
  * The only reason to pass the request to user mode now is when the user 
  mode
  did not register TCE table in the kernel, in all other cases the virtual 
  mode
  handler is expected to do the job
  ---
   .../virtual/kvm/devices/spapr_tce_iommu.txt|  37 +++
   arch/powerpc/include/asm/kvm_host.h|   4 +
   arch/powerpc/kvm/book3s_64_vio.c   | 310 
  -
   arch/powerpc/kvm/book3s_64_vio_hv.c| 122 
   arch/powerpc/kvm/powerpc.c |   1 +
   include/linux/kvm_host.h   |   1 +
   virt/kvm/kvm_main.c|   5 +
   7 files changed, 477 insertions(+), 3 deletions(-)
   create mode 100644 Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
 
  diff --git a/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt 
  b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
  new file mode 100644
  index 000..4bc8fc3
  --- /dev/null
  +++ b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
  @@ -0,0 +1,37 @@
  +SPAPR TCE IOMMU device
  +
  +Capability: KVM_CAP_SPAPR_TCE_IOMMU
  +Architectures: powerpc
  +
  +Device type supported: KVM_DEV_TYPE_SPAPR_TCE_IOMMU
  +
  +Groups:
  +  KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE
  +  Attributes: single attribute with pair { LIOBN, IOMMU fd}
  +
  +This is completely made up device which provides API to link
  +logical bus number (LIOBN) and IOMMU group. The user space has
  +to create a new SPAPR TCE IOMMU device per a logical bus.
  +
  Why not have one device that can handle multimple links?
 
 
  I can do that. If I make it so, it won't even look as a device at all, just
  some weird interface to KVM but ok. What bothers me is it is just a
  May be I do not understand

Re: [PATCH V2 2/2] powerpc/85xx: workaround for chips with MSI hardware errata

2013-09-05 Thread Kumar Gala 

On Apr 2, 2013, at 9:03 PM, Jia Hongtao wrote:

 The MPIC version 2.0 has a MSI errata (errata PIC1 of mpc8544), It causes
 that neither MSI nor MSI-X can work fine. This is a workaround to allow
 MSI-X to function properly.
 
 Signed-off-by: Liu Shuo soniccat@gmail.com
 Signed-off-by: Li Yang le...@freescale.com
 Signed-off-by: Jia Hongtao hongtao@freescale.com
 ---
 Changes for V2:
 * change the name of function mpic_has_errata() to mpic_has_erratum_pic1().
 * move MSI_HW_ERRATA_ENDIAN define to fsl_msi.h with all other defines.
 
 arch/powerpc/sysdev/fsl_msi.c | 40 +---
 arch/powerpc/sysdev/fsl_msi.h |  2 ++
 2 files changed, 39 insertions(+), 3 deletions(-)
 
 diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
 index 178c994..ca1157a 100644
 --- a/arch/powerpc/sysdev/fsl_msi.c
 +++ b/arch/powerpc/sysdev/fsl_msi.c
 @@ -98,8 +98,18 @@ static int fsl_msi_init_allocator(struct fsl_msi *msi_data)
 
 static int fsl_msi_check_device(struct pci_dev *pdev, int nvec, int type)
 {
 - if (type == PCI_CAP_ID_MSIX)
 - pr_debug(fslmsi: MSI-X untested, trying anyway.\n);
 + struct fsl_msi *msi;
 +
 + if (type == PCI_CAP_ID_MSI) {
 + /*
 +  * MPIC version 2.0 has erratum PIC1. For now MSI
 +  * could not work. So check to prevent MSI from
 +  * being used on the board with this erratum.
 +  */
 + list_for_each_entry(msi, msi_head, list)
 + if (msi-feature  MSI_HW_ERRATA_ENDIAN)
 + return -EINVAL;
 + }
 
   return 0;
 }
 @@ -142,7 +152,17 @@ static void fsl_compose_msi_msg(struct pci_dev *pdev, 
 int hwirq,
   msg-address_lo = lower_32_bits(address);
   msg-address_hi = upper_32_bits(address);
 
 - msg-data = hwirq;
 + /*
 +  * MPIC version 2.0 has erratum PIC1. It causes
 +  * that neither MSI nor MSI-X can work fine.
 +  * This is a workaround to allow MSI-X to function
 +  * properly. It only works for MSI-X, we prevent
 +  * MSI on buggy chips in fsl_msi_check_device().
 +  */
 + if (msi_data-feature  MSI_HW_ERRATA_ENDIAN)
 + msg-data = __swab32(hwirq);
 + else
 + msg-data = hwirq;
 
   pr_debug(%s: allocated srs: %d, ibs: %d\n,
   __func__, hwirq / IRQS_PER_MSI_REG, hwirq % IRQS_PER_MSI_REG);
 @@ -361,6 +381,15 @@ static int fsl_msi_setup_hwirq(struct fsl_msi *msi, 
 struct platform_device *dev,
   return 0;
 }
 
 +/* MPIC version 2.0 has erratum PIC1 */
 +static int mpic_has_erratum_pic1(void)
 +{
 + if (fsl_mpic_primary_get_version() == 0x0200)
 + return 1;
 +
 + return 0;
 +}
 +
 static const struct of_device_id fsl_of_msi_ids[];
 static int fsl_of_msi_probe(struct platform_device *dev)
 {
 @@ -423,6 +452,11 @@ static int fsl_of_msi_probe(struct platform_device *dev)
 
   msi-feature = features-fsl_pic_ip;
 
 + if ((features-fsl_pic_ip  FSL_PIC_IP_MASK) == FSL_PIC_IP_MPIC) {
 + if (mpic_has_erratum_pic1())

Get ride of the mpic_has_erratum_pic1() function and just put the test here

 + msi-feature |= MSI_HW_ERRATA_ENDIAN;
 + }
 +
   /*
* Remember the phandle, so that we can match with any PCI nodes
* that have an fsl,msi property.
 diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
 index 8225f86..7389e8e 100644
 --- a/arch/powerpc/sysdev/fsl_msi.h
 +++ b/arch/powerpc/sysdev/fsl_msi.h
 @@ -25,6 +25,8 @@
 #define FSL_PIC_IP_IPIC   0x0002
 #define FSL_PIC_IP_VMPIC  0x0003
 
 +#define MSI_HW_ERRATA_ENDIAN 0x0010
 +

Why does this need to be in the header, why not just have it in the .c only

 struct fsl_msi {
   struct irq_domain *irqhost;
 
 -- 
 1.8.0
 

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

Re: [V2,2/2] powerpc/85xx: workaround for chips with MSI hardware errata

2013-09-05 Thread Scott Wood 
On Wed, 2013-09-04 at 23:00 -0500, Jia Hongtao-B38951 wrote:
  -Original Message-
  From: Jia Hongtao-B38951
  Sent: Monday, July 01, 2013 5:36 PM
  To: Wood Scott-B07421
  Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org
  Subject: RE: [V2,2/2] powerpc/85xx: workaround for chips with MSI
  hardware errata
  
   -Original Message-
   From: Wood Scott-B07421
   Sent: Friday, June 28, 2013 10:29 AM
   To: Jia Hongtao-B38951
   Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Wood
   Scott-
   B07421
   Subject: Re: [V2,2/2] powerpc/85xx: workaround for chips with MSI
   hardware errata
  
   On Wed, Apr 03, 2013 at 10:03:18AM +0800, Hongtao Jia wrote:
The MPIC version 2.0 has a MSI errata (errata PIC1 of mpc8544), It
causes that neither MSI nor MSI-X can work fine. This is a
workaround to allow MSI-X to function properly.
   
Signed-off-by: Liu Shuo soniccat@gmail.com
Signed-off-by: Li Yang le...@freescale.com
Signed-off-by: Jia Hongtao hongtao@freescale.com
  
   Building on 83xx:
  
 arch/powerpc/sysdev/built-in.o: In function `fsl_of_msi_probe':
 fsl_msi.c:(.text+0x1464): undefined reference to
   `fsl_mpic_primary_get_version'
 make[1]: *** [vmlinux] Error 1
 make: *** [sub-make] Error 2
  
   fsl_msi.c supports IPIC as well.
  
   -Scott
  
  Hi Scott,
  I updated the patch to fix this compile error just now.
  please refer to:
  http://patchwork.ozlabs.org/patch/256018/
  
  Thanks.
  -Hongtao
 
 Hi Scott,
 
 The 83xx compile issue has already been fixed.
 Please have a review on this patch.

Oh, sorry -- I missed it because it was marked Changes Requested.
I've changed the status and will consider it for the next batch of
next patches.

In the future, if a patch is miscategorized in patchwork (e.g. says
changes requested when there is no longer a need to submit a new
patch) please mention that specifically and provide the patchwork URL.

-Scott



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

Re: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS

2013-09-05 Thread Scott Wood 
On Tue, 2013-09-03 at 22:30 -0500, Tang Yuantian-B29983 wrote:
 Hi,
 
 These eeproms are never used by kernel. So no need to add them.

The device tree describes the hardware, not what Linux does with it.

-Scott



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

Re: [PATCH V2] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS

2013-09-05 Thread Kumar Gala 

On Sep 4, 2013, at 9:41 PM, Jia Hongtao wrote:

 In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
 The sub-nodes are also reorganized according to right I2C topology.
 
 Signed-off-by: Jia Hongtao hongtao@freescale.com
 ---
 V2 change log:
 Reorganized the sub-nodes under I2C multiplexer to represent right topology.
 
 arch/powerpc/boot/dts/b4qds.dtsi   | 49 +---
 arch/powerpc/boot/dts/t4240qds.dts | 67 ++
 2 files changed, 69 insertions(+), 47 deletions(-)
 
 diff --git a/arch/powerpc/boot/dts/b4qds.dtsi 
 b/arch/powerpc/boot/dts/b4qds.dtsi
 index e6d2f8f..de8cb38 100644
 --- a/arch/powerpc/boot/dts/b4qds.dtsi
 +++ b/arch/powerpc/boot/dts/b4qds.dtsi
 @@ -120,25 +120,36 @@
   };
 
   i2c@118000 {
 - eeprom@50 {
 - compatible = at24,24c64;
 - reg = 0x50;
 - };
 - eeprom@51 {
 - compatible = at24,24c256;
 - reg = 0x51;
 - };
 - eeprom@53 {
 - compatible = at24,24c256;
 - reg = 0x53;
 - };
 - eeprom@57 {
 - compatible = at24,24c256;
 - reg = 0x57;
 - };
 - rtc@68 {
 - compatible = dallas,ds3232;
 - reg = 0x68;
 + pca9547@77 {
 + compatible = philips,pca9547;

We seem to be using nxp instead of philips now.

 + reg = 0x77;
 + #address-cells = 1;
 + #size-cells = 0;
 + channel@0 {

channel should probably be i2c

[same comments below]

 + #address-cells = 1;
 + #size-cells = 0;
 + reg = 0;
 + eeprom@50 {
 + compatible = at24,24c64;
 + reg = 0x50;
 + };
 + eeprom@51 {
 + compatible = at24,24c256;
 + reg = 0x51;
 + };
 + eeprom@53 {
 + compatible = at24,24c256;
 + reg = 0x53;
 + };
 + eeprom@57 {
 + compatible = at24,24c256;
 + reg = 0x57;
 + };
 + rtc@68 {
 + compatible = dallas,ds3232;
 + reg = 0x68;
 + };
 + };
   };
   };
 
 diff --git a/arch/powerpc/boot/dts/t4240qds.dts 
 b/arch/powerpc/boot/dts/t4240qds.dts
 index 0555976..ae68595 100644
 --- a/arch/powerpc/boot/dts/t4240qds.dts
 +++ b/arch/powerpc/boot/dts/t4240qds.dts
 @@ -118,34 +118,45 @@
   };
 
   i2c@118000 {
 - eeprom@51 {
 - compatible = at24,24c256;
 - reg = 0x51;
 - };
 - eeprom@52 {
 - compatible = at24,24c256;
 - reg = 0x52;
 - };
 - eeprom@53 {
 - compatible = at24,24c256;
 - reg = 0x53;
 - };
 - eeprom@54 {
 - compatible = at24,24c256;
 - reg = 0x54;
 - };
 - eeprom@55 {
 - compatible = at24,24c256;
 - reg = 0x55;
 - };
 - eeprom@56 {
 - compatible = at24,24c256;
 - reg = 0x56;
 - };
 - rtc@68 {
 - compatible = dallas,ds3232;
 - reg = 0x68;
 - interrupts = 0x1 0x1 0 0;
 + pca9547@77 {
 + compatible = philips,pca9547;
 + reg = 0x77;
 + #address-cells = 1;
 +

Re: [PATCH v2 3/3] powerpc/85xx: add hardware automatically enter pw20 state

2013-09-05 Thread Scott Wood 
On Tue, 2013-08-27 at 16:41 +0800, Dongsheng Wang wrote:
 From: Wang Dongsheng dongsheng.w...@freescale.com
 
 Using hardware features make core automatically enter PW20 state.
 Set a TB count to hardware, the effective count begins when PW10
 is entered. When the effective period has expired, the core will
 proceed from PW10 to PW20 if no exit conditions have occurred during
 the period.
 
 Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
 ---
 Remove:
 delete setup_idle_hw_governor function.
 delete Fix erratum for rev1.
 
 Move:
 move setup_* into __setup/restore_cpu_e6500.
 
 diff --git a/arch/powerpc/include/asm/reg_booke.h 
 b/arch/powerpc/include/asm/reg_booke.h
 index 8364bbe..e846495 100644
 --- a/arch/powerpc/include/asm/reg_booke.h
 +++ b/arch/powerpc/include/asm/reg_booke.h
 @@ -219,6 +219,7 @@
  
  /* Bit definitions for PWRMGTCR0. */
  #define PWRMGTCR0_ALTIVEC_IDLE   (1  22) /* Altivec idle enable */
 +#define PWRMGTCR0_PW20_WAIT  (1  14) /* PW20 state enable bit */
  
  /* Bit definitions for the MCSR. */
  #define MCSR_MCS 0x8000 /* Machine Check Summary */
 diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S 
 b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
 index 90bbb46..295ccb5 100644
 --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
 +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
 @@ -59,6 +59,7 @@ _GLOBAL(__setup_cpu_e6500)
   bl  .setup_altivec_ivors
  #endif
   bl  setup_altivec_idle
 + bl  setup_pw20_idle
   bl  __setup_cpu_e5500
   mtlrr6
   blr
 @@ -121,6 +122,7 @@ _GLOBAL(__restore_cpu_e6500)
   mflrr5
   bl  .setup_altivec_ivors
   bl  setup_altivec_idle
 + bl  setup_pw20_idle
   bl  __restore_cpu_e5500
   mtlrr5
   blr
 diff --git a/arch/powerpc/platforms/85xx/common.c 
 b/arch/powerpc/platforms/85xx/common.c
 index 93b563b..cdd526e 100644
 --- a/arch/powerpc/platforms/85xx/common.c
 +++ b/arch/powerpc/platforms/85xx/common.c
 @@ -15,12 +15,22 @@
  
  #define ALTIVEC_COUNT_OFFSET 16
  #define ALTIVEC_IDLE_COUNT_MASK  0x003f
 +#define PW20_COUNT_OFFSET8
 +#define PW20_IDLE_COUNT_MASK 0x3f00
  
  /*
   * FIXME - We don't know the AltiVec application scenarios.
   */
  #define ALTIVEC_IDLE_TIME_BIT14 /* 1ms */
  
 +/*
 + * FIXME - We don't know, what time should we let the core into PW20 state.
 + * because we don't know the current state of the cpu load. And threads are
 + * independent, so we can not know the state of different thread has been
 + * idle.
 + */
 +#define PW20_IDLE_TIME_BIT   14 /* 1ms */
 +
  static struct of_device_id __initdata mpc85xx_common_ids[] = {
   { .type = soc, },
   { .compatible = soc, },
 @@ -125,3 +135,25 @@ void setup_altivec_idle(void)
  
   mtspr(SPRN_PWRMGTCR0, altivec_idle);
  }
 +
 +void setup_pw20_idle(void)
 +{
 + u32 pw20_idle;
 +
 + if (!has_pw20_altivec_idle())
 + return;
 +
 + pw20_idle = mfspr(SPRN_PWRMGTCR0);
 +
 + /* Set PW20_WAIT bit, Enable PW20 State */
 + pw20_idle |= PWRMGTCR0_PW20_WAIT;
 +
 + /* Set Automatic PW20 Core Idle Count */
 + /* clear count */
 + pw20_idle = ~PW20_IDLE_COUNT_MASK;
 +
 + /* set count */
 + pw20_idle |= ((MAX_BIT - PW20_IDLE_TIME_BIT)  PW20_COUNT_OFFSET);
 +
 + mtspr(SPRN_PWRMGTCR0, pw20_idle);
 +}

You can't call C code from __restore_cpu_e6500 as you don't have a stack
yet.

-Scott



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

[PATCH v2] powerpc: Default arch idle could cede processor on pseries

2013-09-05 Thread Vaidyanathan Srinivasan 
Hi,

Idle routines on pseries were rearranged so that cpuidle can do an
optimized idle state selection.  However, until cpuidle takes over
during boot, the idle loop spins for a short while.  This actually
affected bootup time since spinning idle sibling threads slows down
master cpu that executes bootup code.

The following patch enables pseries system to yield to hypervisor and
stop spinning by calling cede_processor() until cpuidle can take over
and do optimal idle state selection.

Bootup time can be reduced to half on small guest where most of the
time is spend before device init.

Thanks Ben for the review and suggestions.

--Vaidy

powerpc: Default arch idle could cede processor on pseries

When adding cpuidle support to pSeries, we introduced two
regressions:

  - The new cpuidle backend driver only works under hypervisors
supporting the SLPLAR option, which isn't the case of the
old POWER4 hypervisor and the HV light used on js2x blades

  - The cpuidle driver registers fairly late, meaning that for
a significant portion of the boot process, we end up having
all threads spinning. This slows down the boot process and
increases the overall resource usage if the hypervisor has
shared processors.

This fixes it by implementing a default idle that will cede
to the hypervisor when possible, in a very simple way without
all the bells and whisles of cpuidle.

Reported-by: Paul Mackerras pau...@samba.org
Signed-off-by: Vaidyanathan Srinivasan sva...@linux.vnet.ibm.com
Acked-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org

diff --git a/arch/powerpc/platforms/pseries/setup.c 
b/arch/powerpc/platforms/pseries/setup.c
index c11c823..54b998f 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -354,7 +354,7 @@ static int alloc_dispatch_log_kmem_cache(void)
 }
 early_initcall(alloc_dispatch_log_kmem_cache);
 
-static void pSeries_idle(void)
+static void pseries_lpar_idle(void)
 {
/* This would call on the cpuidle framework, and the back-end pseries
 * driver to  go to idle states
@@ -362,10 +362,22 @@ static void pSeries_idle(void)
if (cpuidle_idle_call()) {
/* On error, execute default handler
 * to go into low thread priority and possibly
-* low power mode.
+* low power mode by cedeing processor to hypervisor
 */
-   HMT_low();
-   HMT_very_low();
+
+   /* Indicate to hypervisor that we are idle. */
+   get_lppaca()-idle = 1;
+
+   /*
+* Yield the processor to the hypervisor.  We return if
+* an external interrupt occurs (which are driven prior
+* to returning here) or if a prod occurs from another
+* processor. When returning here, external interrupts
+* are enabled.
+*/
+   cede_processor();
+
+   get_lppaca()-idle = 0;
}
 }
 
@@ -456,15 +468,14 @@ static void __init pSeries_setup_arch(void)
 
pSeries_nvram_init();
 
-   if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
+   if (firmware_has_feature(FW_FEATURE_LPAR)) {
vpa_init(boot_cpuid);
-   ppc_md.power_save = pSeries_idle;
-   }
-
-   if (firmware_has_feature(FW_FEATURE_LPAR))
+   ppc_md.power_save = pseries_lpar_idle;
ppc_md.enable_pmcs = pseries_lpar_enable_pmcs;
-   else
+   } else {
+   /* No special idle routine */
ppc_md.enable_pmcs = power4_enable_pmcs;
+   }
 
ppc_md.pcibios_root_bridge_prepare = pseries_root_bridge_prepare;
 

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

Re: [PATCH V2 2/2] powerpc/85xx: workaround for chips with MSI hardware errata

2013-09-05 Thread Scott Wood 
On Thu, 2013-09-05 at 13:34 -0500, Kumar Gala wrote:
 On Apr 2, 2013, at 9:03 PM, Jia Hongtao wrote:
  +   msi-feature |= MSI_HW_ERRATA_ENDIAN;
  +   }
  +
  /*
   * Remember the phandle, so that we can match with any PCI nodes
   * that have an fsl,msi property.
  diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
  index 8225f86..7389e8e 100644
  --- a/arch/powerpc/sysdev/fsl_msi.h
  +++ b/arch/powerpc/sysdev/fsl_msi.h
  @@ -25,6 +25,8 @@
  #define FSL_PIC_IP_IPIC   0x0002
  #define FSL_PIC_IP_VMPIC  0x0003
  
  +#define MSI_HW_ERRATA_ENDIAN 0x0010
  +
 
 Why does this need to be in the header, why not just have it in the .c only

Didn't you ask this last time around? :-)

This flag is part of the same numberspace as FSL_PIC_IP_xxx and thus
should be defined in the same place.

-Scott



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

Re: [PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling

2013-09-05 Thread Alexey Kardashevskiy 
On 09/06/2013 04:10 AM, Gleb Natapov wrote:
 On Wed, Sep 04, 2013 at 02:01:28AM +1000, Alexey Kardashevskiy wrote:
 On 09/03/2013 08:53 PM, Gleb Natapov wrote:
 On Mon, Sep 02, 2013 at 01:14:29PM +1000, Alexey Kardashevskiy wrote:
 On 09/01/2013 10:06 PM, Gleb Natapov wrote:
 On Wed, Aug 28, 2013 at 06:50:41PM +1000, Alexey Kardashevskiy wrote:
 This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
 and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
 them to user space which saves time on switching to user space and back.

 Both real and virtual modes are supported. The kernel tries to
 handle a TCE request in the real mode, if fails it passes the request
 to the virtual mode to complete the operation. If it a virtual mode
 handler fails, the request is passed to user space.

 The first user of this is VFIO on POWER. Trampolines to the VFIO external
 user API functions are required for this patch.

 This adds a SPAPR TCE IOMMU KVM device to associate a logical bus
 number (LIOBN) with an VFIO IOMMU group fd and enable in-kernel handling
 of map/unmap requests. The device supports a single attribute which is
 a struct with LIOBN and IOMMU fd. When the attribute is set, the device
 establishes the connection between KVM and VFIO.

 Tests show that this patch increases transmission speed from 220MB/s
 to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).

 Signed-off-by: Paul Mackerras pau...@samba.org
 Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru

 ---

 Changes:
 v9:
 * KVM_CAP_SPAPR_TCE_IOMMU ioctl to KVM replaced with SPAPR TCE IOMMU
 KVM device
 * release_spapr_tce_table() is not shared between different TCE types
 * reduced the patch size by moving VFIO external API
 trampolines to separate patche
 * moved documentation from Documentation/virtual/kvm/api.txt to
 Documentation/virtual/kvm/devices/spapr_tce_iommu.txt

 v8:
 * fixed warnings from check_patch.pl

 2013/07/11:
 * removed multiple #ifdef IOMMU_API as IOMMU_API is always enabled
 for KVM_BOOK3S_64
 * kvmppc_gpa_to_hva_and_get also returns host phys address. Not much 
 sense
 for this here but the next patch for hugepages support will use it more.

 2013/07/06:
 * added realmode arch_spin_lock to protect TCE table from races
 in real and virtual modes
 * POWERPC IOMMU API is changed to support real mode
 * iommu_take_ownership and iommu_release_ownership are protected by
 iommu_table's locks
 * VFIO external user API use rewritten
 * multiple small fixes

 2013/06/27:
 * tce_list page is referenced now in order to protect it from accident
 invalidation during H_PUT_TCE_INDIRECT execution
 * added use of the external user VFIO API

 2013/06/05:
 * changed capability number
 * changed ioctl number
 * update the doc article number

 2013/05/20:
 * removed get_user() from real mode handlers
 * kvm_vcpu_arch::tce_tmp usage extended. Now real mode handler puts there
 translated TCEs, tries realmode_get_page() on those and if it fails, it
 passes control over the virtual mode handler which tries to finish
 the request handling
 * kvmppc_lookup_pte() now does realmode_get_page() protected by BUSY bit
 on a page
 * The only reason to pass the request to user mode now is when the user 
 mode
 did not register TCE table in the kernel, in all other cases the virtual 
 mode
 handler is expected to do the job
 ---
  .../virtual/kvm/devices/spapr_tce_iommu.txt|  37 +++
  arch/powerpc/include/asm/kvm_host.h|   4 +
  arch/powerpc/kvm/book3s_64_vio.c   | 310 
 -
  arch/powerpc/kvm/book3s_64_vio_hv.c| 122 
  arch/powerpc/kvm/powerpc.c |   1 +
  include/linux/kvm_host.h   |   1 +
  virt/kvm/kvm_main.c|   5 +
  7 files changed, 477 insertions(+), 3 deletions(-)
  create mode 100644 Documentation/virtual/kvm/devices/spapr_tce_iommu.txt

 diff --git a/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt 
 b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
 new file mode 100644
 index 000..4bc8fc3
 --- /dev/null
 +++ b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
 @@ -0,0 +1,37 @@
 +SPAPR TCE IOMMU device
 +
 +Capability: KVM_CAP_SPAPR_TCE_IOMMU
 +Architectures: powerpc
 +
 +Device type supported: KVM_DEV_TYPE_SPAPR_TCE_IOMMU
 +
 +Groups:
 +  KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE
 +  Attributes: single attribute with pair { LIOBN, IOMMU fd}
 +
 +This is completely made up device which provides API to link
 +logical bus number (LIOBN) and IOMMU group. The user space has
 +to create a new SPAPR TCE IOMMU device per a logical bus.
 +
 Why not have one device that can handle multimple links?


 I can do that. If I make it so, it won't even look as a device at all, just
 some weird interface to KVM but ok. What bothers me is it is just a
 May be I do not understand usage pattern here. Why do you feel that device
 that can handle multiple

[PATCH 0/6] EEH Support for PHB3

2013-09-05 Thread Gavin Shan 
Naturally, EEH has been supported for PHB3, but we had some mask bits
to disable it because the firmware isn't ready. The series of patch
instends to remove those mask bits and enable EEH for PHB3. Besides,
the output messages from EEH has been reordered to reflect the correct
steps during EEH recovery. Also, we have dedicated data struct for PHB3
diag-data, which is similiar to the case of P7IOC.

Note: We can't recover fenced PHB3 this moment because the f/w still have
some problems, which I'm tracing down. However, the fix shouldn't affect
the logic we have in Linux side.

In order to force frozen PE, you need issue following command or similiar
one on different PHB#:

echo 0x8000  /sys/kernel/debug/powerpc/PCI0003/err_injct_outbound

---

arch/powerpc/include/asm/opal.h  |   65 +++
arch/powerpc/kernel/eeh.c|6 +-
arch/powerpc/platforms/powernv/eeh-ioda.c|  153 ++
arch/powerpc/platforms/powernv/eeh-powernv.c |5 +-
arch/powerpc/platforms/powernv/pci.h |2 +-
5 files changed, 200 insertions(+), 31 deletions(-)

Thanks,
Gavin

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

[PATCH 3/6] powerpc/eeh: Output error number

2013-09-05 Thread Gavin Shan 
The patch prints the error number while failing to retrieve error
log from firmware. It's helpful for debugging.

Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
 arch/powerpc/platforms/powernv/eeh-ioda.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c 
b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 3ee44b0..d60ba3b 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -590,8 +590,8 @@ static int ioda_eeh_get_log(struct eeh_pe *pe, int severity,
phb-diag.blob, PNV_PCI_DIAG_BUF_SIZE);
if (ret) {
spin_unlock_irqrestore(phb-lock, flags);
-   pr_warning(%s: Failed to get log for PHB#%x-PE#%x\n,
-  __func__, hose-global_number, pe-addr);
+   pr_warning(%s: Can't get log for PHB#%x-PE#%x (%lld)\n,
+  __func__, hose-global_number, pe-addr, ret);
return -EIO;
}
 
-- 
1.7.5.4

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

[PATCH 6/6] powerpc/eeh: Reorder output messages

2013-09-05 Thread Gavin Shan 
We already had some output messages from EEH core. Occasionally,
we can see the output messages from EEH core before the stack
dump. That's not what we expected. The patch fixes that and shows
the stack dump prior to output messages from EEH core.

Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
 arch/powerpc/kernel/eeh.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 55593ee..1fb331d 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -327,11 +327,11 @@ static int eeh_phb_check_failure(struct eeh_pe *pe)
/* Isolate the PHB and send event */
eeh_pe_state_mark(phb_pe, EEH_PE_ISOLATED);
eeh_serialize_unlock(flags);
-   eeh_send_failure_event(phb_pe);
 
pr_err(EEH: PHB#%x failure detected\n,
phb_pe-phb-global_number);
dump_stack();
+   eeh_send_failure_event(phb_pe);
 
return 1;
 out:
@@ -454,8 +454,6 @@ int eeh_dev_check_failure(struct eeh_dev *edev)
eeh_pe_state_mark(pe, EEH_PE_ISOLATED);
eeh_serialize_unlock(flags);
 
-   eeh_send_failure_event(pe);
-
/* Most EEH events are due to device driver bugs.  Having
 * a stack trace will help the device-driver authors figure
 * out what happened.  So print that out.
@@ -464,6 +462,8 @@ int eeh_dev_check_failure(struct eeh_dev *edev)
pe-addr, pe-phb-global_number);
dump_stack();
 
+   eeh_send_failure_event(pe);
+
return 1;
 
 dn_unlock:
-- 
1.7.5.4

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

[PATCH 4/6] powerpc/powernv: Double size of log blob

2013-09-05 Thread Gavin Shan 
Each PHB instance (struct pnv_phb) has its corresponding log blob,
which is used to hold the retrieved error log from firmware. The
current size of that (4096) isn't enough for PHB3 case and the patch
makes that double to 8192.

Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
 arch/powerpc/platforms/powernv/pci.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/pci.h 
b/arch/powerpc/platforms/powernv/pci.h
index d633c64..f4bccc8 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -17,7 +17,7 @@ enum pnv_phb_model {
PNV_PHB_MODEL_PHB3,
 };
 
-#define PNV_PCI_DIAG_BUF_SIZE  4096
+#define PNV_PCI_DIAG_BUF_SIZE  8192
 #define PNV_IODA_PE_DEV(1  0)/* PE has single PCI 
device */
 #define PNV_IODA_PE_BUS(1  1)/* PE has primary PCI 
bus   */
 #define PNV_IODA_PE_BUS_ALL(1  2)/* PE has subordinate buses 
*/
-- 
1.7.5.4

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

[PATCH 2/6] powerpc/powernv: Support inbound error injection

2013-09-05 Thread Gavin Shan 
For now, we only support outbound error injection. Actually, the
hardware supports injecting inbound errors as well. The patch enables
to inject inbound errors.

Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
 arch/powerpc/platforms/powernv/eeh-ioda.c |   59 
 1 files changed, 50 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c 
b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 855c1d5..3ee44b0 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -66,26 +66,60 @@ static struct notifier_block ioda_eeh_nb = {
 };
 
 #ifdef CONFIG_DEBUG_FS
-static int ioda_eeh_dbgfs_set(void *data, u64 val)
+static int ioda_eeh_dbgfs_set(void *data, int offset, u64 val)
 {
struct pci_controller *hose = data;
struct pnv_phb *phb = hose-private_data;
 
-   out_be64(phb-regs + 0xD10, val);
+   out_be64(phb-regs + offset, val);
return 0;
 }
 
-static int ioda_eeh_dbgfs_get(void *data, u64 *val)
+static int ioda_eeh_dbgfs_get(void *data, int offset, u64 *val)
 {
struct pci_controller *hose = data;
struct pnv_phb *phb = hose-private_data;
 
-   *val = in_be64(phb-regs + 0xD10);
+   *val = in_be64(phb-regs + offset);
return 0;
 }
 
-DEFINE_SIMPLE_ATTRIBUTE(ioda_eeh_dbgfs_ops, ioda_eeh_dbgfs_get,
-   ioda_eeh_dbgfs_set, 0x%llx\n);
+static int ioda_eeh_outb_dbgfs_set(void *data, u64 val)
+{
+   return ioda_eeh_dbgfs_set(data, 0xD10, val);
+}
+
+static int ioda_eeh_outb_dbgfs_get(void *data, u64 *val)
+{
+   return ioda_eeh_dbgfs_get(data, 0xD10, val);
+}
+
+static int ioda_eeh_inbA_dbgfs_set(void *data, u64 val)
+{
+   return ioda_eeh_dbgfs_set(data, 0xD90, val);
+}
+
+static int ioda_eeh_inbA_dbgfs_get(void *data, u64 *val)
+{
+   return ioda_eeh_dbgfs_get(data, 0xD90, val);
+}
+
+static int ioda_eeh_inbB_dbgfs_set(void *data, u64 val)
+{
+   return ioda_eeh_dbgfs_set(data, 0xE10, val);
+}
+
+static int ioda_eeh_inbB_dbgfs_get(void *data, u64 *val)
+{
+   return ioda_eeh_dbgfs_get(data, 0xE10, val);
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(ioda_eeh_outb_dbgfs_ops, ioda_eeh_outb_dbgfs_get,
+   ioda_eeh_outb_dbgfs_set, 0x%llx\n);
+DEFINE_SIMPLE_ATTRIBUTE(ioda_eeh_inbA_dbgfs_ops, ioda_eeh_inbA_dbgfs_get,
+   ioda_eeh_inbA_dbgfs_set, 0x%llx\n);
+DEFINE_SIMPLE_ATTRIBUTE(ioda_eeh_inbB_dbgfs_ops, ioda_eeh_inbB_dbgfs_get,
+   ioda_eeh_inbB_dbgfs_set, 0x%llx\n);
 #endif /* CONFIG_DEBUG_FS */
 
 /**
@@ -123,10 +157,17 @@ static int ioda_eeh_post_init(struct pci_controller *hose)
}
 
 #ifdef CONFIG_DEBUG_FS
-   if (phb-dbgfs)
-   debugfs_create_file(err_injct, 0600,
+   if (phb-dbgfs) {
+   debugfs_create_file(err_injct_outbound, 0600,
+   phb-dbgfs, hose,
+   ioda_eeh_outb_dbgfs_ops);
+   debugfs_create_file(err_injct_inboundA, 0600,
phb-dbgfs, hose,
-   ioda_eeh_dbgfs_ops);
+   ioda_eeh_inbA_dbgfs_ops);
+   debugfs_create_file(err_injct_inboundB, 0600,
+   phb-dbgfs, hose,
+   ioda_eeh_inbB_dbgfs_ops);
+   }
 #endif
 
phb-eeh_state |= PNV_EEH_STATE_ENABLED;
-- 
1.7.5.4

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

[PATCH 5/6] powerpc/eeh: Output PHB3 diag-data

2013-09-05 Thread Gavin Shan 
The patch adds function ioda_eeh_phb3_phb_diag() to dump PHB3
PHB diag-data. That's called while detecting informative errors
or frozen PE on the specific PHB.

Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
 arch/powerpc/include/asm/opal.h   |   65 ++
 arch/powerpc/platforms/powernv/eeh-ioda.c |   70 +
 2 files changed, 135 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 029fe85..fed4b7d 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -444,10 +444,12 @@ enum {
 
 enum {
OPAL_PHB_ERROR_DATA_TYPE_P7IOC = 1,
+   OPAL_PHB_ERROR_DATA_TYPE_PHB3 = 2
 };
 
 enum {
OPAL_P7IOC_NUM_PEST_REGS = 128,
+   OPAL_PHB3_NUM_PEST_REGS = 256
 };
 
 struct OpalIoPhbErrorCommon {
@@ -515,6 +517,69 @@ struct OpalIoP7IOCPhbErrorData {
uint64_t pestB[OPAL_P7IOC_NUM_PEST_REGS];
 };
 
+struct OpalIoPhb3ErrorData {
+   struct OpalIoPhbErrorCommon common;
+
+   uint32_t brdgCtl;
+
+   /* PHB3 UTL regs */
+   uint32_t portStatusReg;
+   uint32_t rootCmplxStatus;
+   uint32_t busAgentStatus;
+
+   /* PHB3 cfg regs */
+   uint32_t deviceStatus;
+   uint32_t slotStatus;
+   uint32_t linkStatus;
+   uint32_t devCmdStatus;
+   uint32_t devSecStatus;
+
+   /* cfg AER regs */
+   uint32_t rootErrorStatus;
+   uint32_t uncorrErrorStatus;
+   uint32_t corrErrorStatus;
+   uint32_t tlpHdr1;
+   uint32_t tlpHdr2;
+   uint32_t tlpHdr3;
+   uint32_t tlpHdr4;
+   uint32_t sourceId;
+
+   uint32_t rsv3;
+
+   /* Record data about the call to allocate a buffer */
+   uint64_t errorClass;
+   uint64_t correlator;
+
+   uint64_t nFir;  /* 000 */
+   uint64_t nFirMask;  /* 003 */
+   uint64_t nFirWOF;   /* 008 */
+
+   /* PHB3 MMIO Error Regs */
+   uint64_t phbPlssr;  /* 120 */
+   uint64_t phbCsr;/* 110 */
+   uint64_t lemFir;/* C00 */
+   uint64_t lemErrorMask;  /* C18 */
+   uint64_t lemWOF;/* C40 */
+   uint64_t phbErrorStatus;/* C80 */
+   uint64_t phbFirstErrorStatus;   /* C88 */
+   uint64_t phbErrorLog0;  /* CC0 */
+   uint64_t phbErrorLog1;  /* CC8 */
+   uint64_t mmioErrorStatus;   /* D00 */
+   uint64_t mmioFirstErrorStatus;  /* D08 */
+   uint64_t mmioErrorLog0; /* D40 */
+   uint64_t mmioErrorLog1; /* D48 */
+   uint64_t dma0ErrorStatus;   /* D80 */
+   uint64_t dma0FirstErrorStatus;  /* D88 */
+   uint64_t dma0ErrorLog0; /* DC0 */
+   uint64_t dma0ErrorLog1; /* DC8 */
+   uint64_t dma1ErrorStatus;   /* E00 */
+   uint64_t dma1FirstErrorStatus;  /* E08 */
+   uint64_t dma1ErrorLog0; /* E40 */
+   uint64_t dma1ErrorLog1; /* E48 */
+   uint64_t pestA[OPAL_PHB3_NUM_PEST_REGS];
+   uint64_t pestB[OPAL_PHB3_NUM_PEST_REGS];
+};
+
 typedef struct oppanel_line {
const char *line;
uint64_tline_len;
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c 
b/arch/powerpc/platforms/powernv/eeh-ioda.c
index d60ba3b..be68fd8 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -754,6 +754,73 @@ static void ioda_eeh_p7ioc_phb_diag(struct pci_controller 
*hose,
}
 }
 
+static void ioda_eeh_phb3_phb_diag(struct pci_controller *hose,
+   struct OpalIoPhbErrorCommon *common)
+{
+   struct OpalIoPhb3ErrorData *data;
+   int i;
+
+   data = (struct OpalIoPhb3ErrorData*)common;
+   pr_info(PHB3 PHB#%x Diag-data (Version: %d)\n\n,
+   hose-global_number, common-version);
+
+   pr_info(  brdgCtl:  %08x\n, data-brdgCtl);
+
+   pr_info(  portStatusReg:%08x\n, data-portStatusReg);
+   pr_info(  rootCmplxStatus:  %08x\n, data-rootCmplxStatus);
+   pr_info(  busAgentStatus:   %08x\n, data-busAgentStatus);
+
+   pr_info(  deviceStatus: %08x\n, data-deviceStatus);
+   pr_info(  slotStatus:   %08x\n, data-slotStatus);
+   pr_info(  linkStatus:   %08x\n, data-linkStatus);
+   pr_info(  devCmdStatus: %08x\n, data-devCmdStatus);
+   pr_info(  devSecStatus: %08x\n, data-devSecStatus);
+
+   pr_info(  rootErrorStatus:  %08x\n, data-rootErrorStatus);
+   pr_info(  uncorrErrorStatus:%08x\n, data-uncorrErrorStatus);
+   pr_info(  corrErrorStatus:  %08x\n, data-corrErrorStatus);
+   pr_info(  tlpHdr1:  %08x\n, data-tlpHdr1);
+   pr_info(  tlpHdr2:  %08x\n, data-tlpHdr2);
+   pr_info(  tlpHdr3:  %08x\n, data-tlpHdr3);
+   pr_info(  tlpHdr4:  %08x\n,

[git pull] Please pull powerpc.git next branch

2013-09-05 Thread Benjamin Herrenschmidt 
Hi Linus !

Here's the powerpc batch for this merge window. Some of the highlights are:

 * A bunch of endian fixes ! We don't have full LE support yet in that
release but this contains a lot of fixes all over arch/powerpc to use the
proper accessors, call the firmware with the right endian mode, etc...

 * A few updates to our powernv platform (non-virtualized, the one
to run KVM on), among other, support for bridging the P8 LPC bus for UARTs,
support and some EEH fixes.
 
 * Some mpc51xx clock API cleanups in preparation for a clock API overhaul

 * A pile of cleanups of our old math emulation code, including better
support for using it to emulate optional FP instructions on embedded
chips that otherwise have a HW FPU.

 * Some infrastructure in selftest, for powerpc now, but could be generalized,
initially used by some tests for our perf instruction counting code.

 * A pile of fixes for hotplug on pseries (that was seriously bitrotting)

 * The usual slew of freescale embedded updates, new boards, 64-bit hiberation
support, e6500 core PMU support, etc...

Cheers,
Ben.

The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8:

  Linux 3.11-rc5 (2013-08-11 18:04:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next

for you to fetch changes up to 9f24b0c9ef9b6b1292579c9e2cd7ff07ddc372b7:

  powerpc: Correct FSCR bit definitions (2013-09-05 17:29:20 +1000)


Alistair Popple (4):
  powerpc: More little endian fixes for prom.c
  powerpc: More little endian fixes for setup-common.c
  powerpc: Little endian fixes for legacy_serial.c
  powerpc: Make NUMA device node code endian safe

Andy Fleming (2):
  powerpc: Add smp_generic_cpu_bootable
  powerpc: Convert platforms to smp_generic_cpu_bootable

Anton Blanchard (29):
  powerpc: Align p_toc
  powerpc: Handle unaligned ldbrx/stdbrx
  powerpc: Wrap MSR macros with parentheses
  powerpc: Remove SAVE_VSRU and REST_VSRU macros
  powerpc: Simplify logic in include/uapi/asm/elf.h
  powerpc/pseries: Simplify H_GET_TERM_CHAR
  powerpc: Fix a number of sparse warnings
  powerpc/pci: Don't use bitfield for force_32bit_msi
  powerpc: Stop using non-architected shared_proc field in lppaca
  powerpc: Make RTAS device tree accesses endian safe
  powerpc: Make cache info device tree accesses endian safe
  powerpc: Make RTAS calls endian safe
  powerpc: Make logical to real cpu mapping code endian safe
  powerpc: Add some endian annotations to time and xics code
  powerpc: Fix some endian issues in xics code
  powerpc: of_parse_dma_window should take a __be32 *dma_window
  powerpc: Make device tree accesses in cache info code endian safe
  powerpc: Make device tree accesses in HVC VIO console endian safe
  powerpc: Make device tree accesses in VIO subsystem endian safe
  powerpc: Make OF PCI device tree accesses endian safe
  powerpc: Make PCI device node device tree accesses endian safe
  powerpc: Add endian annotations to lppaca, slb_shadow and dtl_entry
  powerpc: Fix little endian lppaca, slb_shadow and dtl_entry
  powerpc: Emulate instructions in little endian mode
  powerpc: Little endian SMP IPI demux
  powerpc/pseries: Fix endian issues in H_GET_TERM_CHAR/H_PUT_TERM_CHAR
  powerpc: Fix little endian coredumps
  powerpc: Make rwlocks endian safe
  powerpc: Never handle VSX alignment exceptions from kernel

Benjamin Herrenschmidt (21):
  Merge remote-tracking branch 'scott/next' into next
  powerpc/pmac: Early debug output on screen on 64-bit macs
  powerpc: Better split CONFIG_PPC_INDIRECT_PIO and CONFIG_PPC_INDIRECT_MMIO
  powerpc/powernv: Update opal.h to add new LPC and XSCOM functions
  powerpc/powernv: Add helper to get ibm,chip-id of a node
  powerpc/powernv: Add PIO accessors for Power8 LPC bus
  powerpc: Cleanup udbg_16550 and add support for LPC PIO-only UARTs
  powerpc: Check status property before adding legacy ISA serial ports
  powerpc/powernv: Don't crash if there are no OPAL consoles
  powerpc/powernv: Enable detection of legacy UARTs
  Revert powerpc/e500: Update compilation flags with core specific options
  powerpc: Make prom_init.c endian safe
  powerpc/wsp: Fix early debug build
  Merge remote-tracking branch 'scott/next' into next
  Merge branch 'merge' into next
  powerpc/btext: Fix CONFIG_PPC_EARLY_DEBUG_BOOTX on ppc32
  powerpc: Don't Oops when accessing /proc/powerpc/lparcfg without 
hypervisor
  powerpc/powernv: Return secondary CPUs to firmware on kexec
  Merge branch 'merge' into next
  powerpc/pseries: Move lparcfg.c to platforms/pseries
  Merge remote-tracking branch 'agust/next' into next

Catalin Udma (2):
  powerpc/perf: increase the perf HW events to 6

RE: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS

2013-09-05 Thread Tang Yuantian-B29983 

 -Original Message-
 From: Wood Scott-B07421
 Sent: 2013年9月6日 星期五 2:41
 To: Tang Yuantian-B29983
 Cc: Yang,Wei; Jia Hongtao-B38951; Wood Scott-B07421; linuxppc-
 d...@lists.ozlabs.org
 Subject: Re: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and
 T4240QDS
 
 On Tue, 2013-09-03 at 22:30 -0500, Tang Yuantian-B29983 wrote:
  Hi,
 
  These eeproms are never used by kernel. So no need to add them.
 
 The device tree describes the hardware, not what Linux does with it.
 
Missing some nodes doesn't mean it is not describing the hardware.
There are almost fifty I2C devices on T4 connected to PCA9547.
Do you think we need to list them all?

Regards,
Yuantian

 -Scott
 

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

RE: [V2,2/2] powerpc/85xx: workaround for chips with MSI hardware errata

2013-09-05 Thread Jia Hongtao-B38951 


 -Original Message-
 From: Wood Scott-B07421
 Sent: Friday, September 06, 2013 1:57 AM
 To: Jia Hongtao-B38951
 Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org;
 ga...@kernel.crashing.org
 Subject: Re: [V2,2/2] powerpc/85xx: workaround for chips with MSI
 hardware errata
 
 On Wed, 2013-09-04 at 23:00 -0500, Jia Hongtao-B38951 wrote:
   -Original Message-
   From: Jia Hongtao-B38951
   Sent: Monday, July 01, 2013 5:36 PM
   To: Wood Scott-B07421
   Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org
   Subject: RE: [V2,2/2] powerpc/85xx: workaround for chips with MSI
   hardware errata
  
-Original Message-
From: Wood Scott-B07421
Sent: Friday, June 28, 2013 10:29 AM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Wood
Scott-
B07421
Subject: Re: [V2,2/2] powerpc/85xx: workaround for chips with MSI
hardware errata
   
On Wed, Apr 03, 2013 at 10:03:18AM +0800, Hongtao Jia wrote:
 The MPIC version 2.0 has a MSI errata (errata PIC1 of mpc8544),
 It causes that neither MSI nor MSI-X can work fine. This is a
 workaround to allow MSI-X to function properly.

 Signed-off-by: Liu Shuo soniccat@gmail.com
 Signed-off-by: Li Yang le...@freescale.com
 Signed-off-by: Jia Hongtao hongtao@freescale.com
   
Building on 83xx:
   
  arch/powerpc/sysdev/built-in.o: In function `fsl_of_msi_probe':
  fsl_msi.c:(.text+0x1464): undefined reference to
`fsl_mpic_primary_get_version'
  make[1]: *** [vmlinux] Error 1
  make: *** [sub-make] Error 2
   
fsl_msi.c supports IPIC as well.
   
-Scott
  
   Hi Scott,
   I updated the patch to fix this compile error just now.
   please refer to:
   http://patchwork.ozlabs.org/patch/256018/
  
   Thanks.
   -Hongtao
 
  Hi Scott,
 
  The 83xx compile issue has already been fixed.
  Please have a review on this patch.
 
 Oh, sorry -- I missed it because it was marked Changes Requested.
 I've changed the status and will consider it for the next batch of next
 patches.
 
 In the future, if a patch is miscategorized in patchwork (e.g. says
 changes requested when there is no longer a need to submit a new
 patch) please mention that specifically and provide the patchwork URL.
 
 -Scott
 

Ok, got it.
Sorry for your inconvenient. 

-Hongtao

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

RE: [PATCH V2] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS

2013-09-05 Thread Jia Hongtao-B38951 
 -Original Message-
 From: Kumar Gala [mailto:ga...@kernel.crashing.org]
 Sent: Friday, September 06, 2013 2:41 AM
 To: Jia Hongtao-B38951
 Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
 wei.y...@windriver.com
 Subject: Re: [PATCH V2] powerpc: Add I2C bus multiplexer node for B4 and
 T4240QDS
 
 
 On Sep 4, 2013, at 9:41 PM, Jia Hongtao wrote:
 
  In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
  The sub-nodes are also reorganized according to right I2C topology.
 
  Signed-off-by: Jia Hongtao hongtao@freescale.com
  ---
  V2 change log:
  Reorganized the sub-nodes under I2C multiplexer to represent right
 topology.
 
  arch/powerpc/boot/dts/b4qds.dtsi   | 49 +---
  arch/powerpc/boot/dts/t4240qds.dts | 67 ++-
 ---
  2 files changed, 69 insertions(+), 47 deletions(-)
 
  diff --git a/arch/powerpc/boot/dts/b4qds.dtsi
 b/arch/powerpc/boot/dts/b4qds.dtsi
  index e6d2f8f..de8cb38 100644
  --- a/arch/powerpc/boot/dts/b4qds.dtsi
  +++ b/arch/powerpc/boot/dts/b4qds.dtsi
  @@ -120,25 +120,36 @@
  };
 
  i2c@118000 {
  -   eeprom@50 {
  -   compatible = at24,24c64;
  -   reg = 0x50;
  -   };
  -   eeprom@51 {
  -   compatible = at24,24c256;
  -   reg = 0x51;
  -   };
  -   eeprom@53 {
  -   compatible = at24,24c256;
  -   reg = 0x53;
  -   };
  -   eeprom@57 {
  -   compatible = at24,24c256;
  -   reg = 0x57;
  -   };
  -   rtc@68 {
  -   compatible = dallas,ds3232;
  -   reg = 0x68;
  +   pca9547@77 {
  +   compatible = philips,pca9547;
 
 We seem to be using nxp instead of philips now.
 
  +   reg = 0x77;
  +   #address-cells = 1;
  +   #size-cells = 0;
  +   channel@0 {
 
 channel should probably be i2c


Is there any standard for the name?
i2c is ok but I think channel is more intuitional.

Hi Scott,
What do you think of it.

Thanks.
-Hongtao


 
 [same comments below]
 
  +   #address-cells = 1;
  +   #size-cells = 0;
  +   reg = 0;
  +   eeprom@50 {
  +   compatible = at24,24c64;
  +   reg = 0x50;
  +   };
  +   eeprom@51 {
  +   compatible = at24,24c256;
  +   reg = 0x51;
  +   };
  +   eeprom@53 {
  +   compatible = at24,24c256;
  +   reg = 0x53;
  +   };
  +   eeprom@57 {
  +   compatible = at24,24c256;
  +   reg = 0x57;
  +   };
  +   rtc@68 {
  +   compatible = dallas,ds3232;
  +   reg = 0x68;
  +   };
  +   };
  };
  };
 
  diff --git a/arch/powerpc/boot/dts/t4240qds.dts
 b/arch/powerpc/boot/dts/t4240qds.dts
  index 0555976..ae68595 100644
  --- a/arch/powerpc/boot/dts/t4240qds.dts
  +++ b/arch/powerpc/boot/dts/t4240qds.dts
  @@ -118,34 +118,45 @@
  };
 
  i2c@118000 {
  -   eeprom@51 {
  -   compatible = at24,24c256;
  -   reg = 0x51;
  -   };
  -   eeprom@52 {
  -   compatible = at24,24c256;
  -   reg = 0x52;
  -   };
  -   eeprom@53 {
  -   compatible = at24,24c256;
  -   reg = 0x53;
  -   };
  -   eeprom@54 {
  -   compatible = at24,24c256;
  -   reg = 0x54;
  -   };
  -   eeprom@55 {
  -   compatible = at24,24c256;
  -   reg = 0x55;
  -   };
  -   eeprom@56 {
  -   compatible = at24,24c256;
  -   reg = 0x56;
  -   };