[PATCH] powerpc/powernv: Fix endian issues in memory error handling code

2014-06-03 Thread Anton Blanchard
struct OpalMemoryErrorData is passed to us from firmware, so we
have to byteswap it.

Signed-off-by: Anton Blanchard 
---

Having enums in a firmware interface concerns me, but that cleanup
can be in a subsequent patch.

Mahesh, could you give this a test to see if it works?

Index: b/arch/powerpc/include/asm/opal.h
===
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -482,7 +482,7 @@ enum OpalMemErr_DynErrType {
 struct OpalMemoryErrorData {
enum OpalMemErr_Version version:8;  /* 0x00 */
enum OpalMemErrType type:8; /* 0x01 */
-   uint16_tflags;  /* 0x02 */
+   __be16  flags;  /* 0x02 */
uint8_t reserved_1[4];  /* 0x04 */
 
union {
@@ -490,15 +490,15 @@ struct OpalMemoryErrorData {
struct {
enum OpalMemErr_ResilErrType resil_err_type:8;
uint8_t reserved_1[7];
-   uint64_tphysical_address_start;
-   uint64_tphysical_address_end;
+   __be64  physical_address_start;
+   __be64  physical_address_end;
} resilience;
/* Dynamic memory deallocation error info */
struct {
enum OpalMemErr_DynErrType dyn_err_type:8;
uint8_t reserved_1[7];
-   uint64_tphysical_address_start;
-   uint64_tphysical_address_end;
+   __be64  physical_address_start;
+   __be64  physical_address_end;
} dyn_dealloc;
} u;
 };
Index: b/arch/powerpc/platforms/powernv/opal-memory-errors.c
===
--- a/arch/powerpc/platforms/powernv/opal-memory-errors.c
+++ b/arch/powerpc/platforms/powernv/opal-memory-errors.c
@@ -47,12 +47,12 @@ static void handle_memory_error_event(st
  __func__, merr_evt->type);
switch (merr_evt->type) {
case OPAL_MEM_ERR_TYPE_RESILIENCE:
-   paddr_start = merr_evt->u.resilience.physical_address_start;
-   paddr_end = merr_evt->u.resilience.physical_address_end;
+   paddr_start = 
be64_to_cpu(merr_evt->u.resilience.physical_address_start);
+   paddr_end = 
be64_to_cpu(merr_evt->u.resilience.physical_address_end);
break;
case OPAL_MEM_ERR_TYPE_DYN_DALLOC:
-   paddr_start = merr_evt->u.dyn_dealloc.physical_address_start;
-   paddr_end = merr_evt->u.dyn_dealloc.physical_address_end;
+   paddr_start = 
be64_to_cpu(merr_evt->u.dyn_dealloc.physical_address_start);
+   paddr_end = 
be64_to_cpu(merr_evt->u.dyn_dealloc.physical_address_end);
break;
default:
return;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] KVM: PPC: BOOK3S: PR: Fix PURR and SPURR emulation

2014-06-03 Thread Paul Mackerras
On Tue, Jun 03, 2014 at 05:46:11PM +0530, Aneesh Kumar K.V wrote:
> We use time base for PURR and SPURR emulation with PR KVM since we
> are emulating a single threaded core. When using time base
> we need to make sure that we don't accumulate time spent in the host
> in PURR and SPURR value.

Mostly looks good except for this...

> @@ -170,6 +175,11 @@ void kvmppc_copy_from_svcpu(struct kvm_vcpu *vcpu,
>  
>  out:
>   preempt_enable();
> + /*
> +  * Update purr and spurr using time base
> +  */
> + vcpu->arch.purr += get_tb() - vcpu->arch.entry_tb;
> + vcpu->arch.spurr += get_tb() - vcpu->arch.entry_tb;

You need to do those updates before the "out:" label.  Otherwise if
this function gets called with !svcpu->in_use (which can happen if
CONFIG_PREEMPT is enabled) we would do these updates a second time for
one guest exit.  The thing is that kvmppc_copy_from_svcpu() can get
called from kvmppc_core_vcpu_put_pr() if the vcpu task gets preempted
on the way out from the guest before we get to the regular call of
kvmppc_copy_from_svcpu().  It would then get called again when the
task gets to run, but this time it does nothing because svcpu->in_use
is false.

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

[PATCH 1/1] powerpc: correct DSCR during TM context switch

2014-06-03 Thread Sam Bobroff
Correct the DSCR SPR becoming temporarily corrupted when a task is
context switched when within a transaction. It is corrected when
the transaction is aborted (which will happen after a context switch)
but if the task has suspended (TSUSPEND) the transaction the incorrect
value can be seen.

The problem is caused by saving a thread's DSCR after it has already
been reverted to the CPU's default value:

__switch_to() calls __switch_to_tm()
which calls tm_reclaim_task()
which calls tm_reclaim_thread()
which calls tm_reclaim() where the DSCR is reset
__switch_to() calls _switch
_switch() saves the DSCR to thread.dscr

The fix is to treat the DSCR similarly to the TAR and save it early
in __switch_to().

The program below will expose the problem:

  #include 
  #include 
  #include 
  #include 
  #include 

  #define TBEGIN  ".long 0x7C00051D ;"
  #define TEND".long 0x7C00055D ;"
  #define TCHECK  ".long 0x7C00059C ;"
  #define TSUSPEND".long 0x7C0005DD ;"
  #define TRESUME ".long 0x7C2005DD ;"
  #define SPRN_TEXASR 0x82
  #define SPRN_DSCR   0x03

  int main(void) {
uint64_t i = 0, rv, dscr1 = 1, dscr2, texasr;

for (;;) {
  rv = 1;
  asm __volatile__ (
  "ld  3, %[dscr1];"
  "mtspr   %[sprn_dscr], 3;"
  TBEGIN
  "beq 1f;"
  TSUSPEND
  "2: ;"
  TCHECK
  "bc  4, 0, 2b;"
  "mfspr   3, %[sprn_dscr];"
  "std 3, %[dscr2];"
  "mfspr   3, %[sprn_texasr];"
  "std 3, %[texasr];"
  TRESUME
  TEND
  "li  %[rv], 0;"
  "1: ;"
  : [rv]"=r"(rv), [dscr2]"=m"(dscr2), [texasr]"=m"(texasr)
  : [dscr1]"m"(dscr1)
  , [sprn_dscr]"i"(SPRN_DSCR), [sprn_texasr]"i"(SPRN_TEXASR)
  : "memory", "r3"
  );
  assert(rv);
  if ((texasr >> 56) == TM_CAUSE_RESCHED) {
putchar('!');
fflush(stdout);
i++;
  }
  else {
putchar('.');
fflush(stdout);
  }
  if (dscr2 != dscr1) {
printf("\n DSCR incorrect: 0x%lx (expecting 0x%lx)\n", dscr2, 
dscr1);
exit(EXIT_FAILURE);
  }
  if (i > 10) {
printf("\n DSCR TM context switching seems OK.\n");
exit(EXIT_SUCCESS);
  }
}
  }

Signed-off-by: Sam Bobroff 
---
 arch/powerpc/include/asm/switch_to.h |6 --
 arch/powerpc/kernel/entry_64.S   |6 --
 arch/powerpc/kernel/process.c|8 
 3 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/include/asm/switch_to.h 
b/arch/powerpc/include/asm/switch_to.h
index 2737f46..3efd0e5 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -16,13 +16,15 @@ struct thread_struct;
 extern struct task_struct *_switch(struct thread_struct *prev,
   struct thread_struct *next);
 #ifdef CONFIG_PPC_BOOK3S_64
-static inline void save_tar(struct thread_struct *prev)
+static inline void save_early_sprs(struct thread_struct *prev)
 {
if (cpu_has_feature(CPU_FTR_ARCH_207S))
prev->tar = mfspr(SPRN_TAR);
+   if (cpu_has_feature(CPU_FTR_DSCR))
+   prev->dscr = mfspr(SPRN_DSCR);
 }
 #else
-static inline void save_tar(struct thread_struct *prev) {}
+static inline void save_early_sprs(struct thread_struct *prev) {}
 #endif
 
 extern void enable_kernel_fp(void);
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 662c6dd..a107f4a 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -432,12 +432,6 @@ BEGIN_FTR_SECTION
std r24,THREAD_VRSAVE(r3)
 END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
 #endif /* CONFIG_ALTIVEC */
-#ifdef CONFIG_PPC64
-BEGIN_FTR_SECTION
-   mfspr   r25,SPRN_DSCR
-   std r25,THREAD_DSCR(r3)
-END_FTR_SECTION_IFSET(CPU_FTR_DSCR)
-#endif
and.r0,r0,r22
beq+1f
andcr22,r22,r0
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index e247898..8d2065e 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -771,15 +771,15 @@ struct task_struct *__switch_to(struct task_struct *prev,
 
WARN_ON(!irqs_disabled());
 
-   /* Back up the TAR across context switches.
+   /* Back up the TAR and DSCR across context switches.
 * Note that the TAR is not available for use in the kernel.  (To
 * provide this, the TAR should be backed up/restored on exception
 * entry/exit instead, and be in pt_regs.  FIXME, this should be in
 * pt_regs anyway (for debug).)
-* Save the TAR here before we do treclaim/trecheckpoint as these
-* will change the TAR.
+* Save the TAR and DSCR here before we do treclaim/trecheckpoint as
+* these will change them.
 */
-   save_tar(&prev->thread);
+   save_early_sprs(&prev->thread);
 
__switch_to_tm(prev);
 
-- 
1.7.10.4

_

[PATCH] powerpc/eeh: skip eeh sysfs when eeh is disabled

2014-06-03 Thread Wei Yang
When eeh is not enabled, and hotplug two pci devices on the same bus, eeh
related sysfs would be added twice for the first added pci device. Since the
eeh_dev is not created when eeh is not enabled.

This patch adds the check, if eeh is not enabled, eeh sysfs will not be
created.

After applying this patch, following warnings are reduced:

sysfs: cannot create duplicate filename 
'/devices/pci:00/:00:00.0/eeh_mode'
sysfs: cannot create duplicate filename 
'/devices/pci:00/:00:00.0/eeh_config_addr'
sysfs: cannot create duplicate filename 
'/devices/pci:00/:00:00.0/eeh_pe_config_addr'

Signed-off-by: Wei Yang 
Acked-by: Gavin Shan 
---
 arch/powerpc/kernel/eeh_sysfs.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/kernel/eeh_sysfs.c b/arch/powerpc/kernel/eeh_sysfs.c
index 5d753d4..e2595ba 100644
--- a/arch/powerpc/kernel/eeh_sysfs.c
+++ b/arch/powerpc/kernel/eeh_sysfs.c
@@ -59,6 +59,9 @@ void eeh_sysfs_add_device(struct pci_dev *pdev)
struct eeh_dev *edev = pci_dev_to_eeh_dev(pdev);
int rc=0;
 
+   if (!eeh_enabled())
+   return;
+
if (edev && (edev->mode & EEH_DEV_SYSFS))
return;
 
-- 
1.7.9.5

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

[PATCH] powerpc: 64bit sendfile is capped at 2GB

2014-06-03 Thread Anton Blanchard
commit 8f9c0119d7ba (compat: fs: Generic compat_sys_sendfile
implementation) changed the PowerPC 64bit sendfile call from
sys_sendile64 to sys_sendfile.

Unfortunately this broke sendfile of lengths greater than 2G because
sys_sendfile caps at MAX_NON_LFS. Restore what we had previously which
fixes the bug.

Cc: sta...@vger.kernel.org
Signed-off-by: Anton Blanchard 
---

diff --git a/arch/powerpc/include/asm/systbl.h 
b/arch/powerpc/include/asm/systbl.h
index ac062f5..35f8f2f 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -190,7 +190,7 @@ SYSCALL_SPU(getcwd)
 SYSCALL_SPU(capget)
 SYSCALL_SPU(capset)
 COMPAT_SYS(sigaltstack)
-COMPAT_SYS_SPU(sendfile)
+SYSX_SPU(sys_sendfile64,compat_sys_sendfile,sys_sendfile)
 SYSCALL(ni_syscall)
 SYSCALL(ni_syscall)
 PPC_SYS(vfork)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc, kexec: Fix "Processor X is stuck" issue during kexec from ST mode

2014-06-03 Thread Benjamin Herrenschmidt
On Wed, 2014-06-04 at 01:58 +0530, Srivatsa S. Bhat wrote:
> Yep, that makes sense. But unfortunately I don't have enough insight into
> why exactly powerpc has to online the CPUs before doing a kexec. I just
> know from the commit log and the comment mentioned above (and from my own
> experiments) that the CPUs will get stuck if they were offline. Perhaps
> somebody more knowledgeable can explain this in detail and suggest a proper
> long-term solution.
> 
> Matt, Ben, any thoughts on this?

The problem is with our "soft offline" which we do on some platforms. When we
offline we don't actually send the CPUs back to firmware or anything like that.

We put them into a very low low power loop inside Linux.

The new kernel has no way to extract them from that loop. So we must re-"online"
them before we kexec so they can be passed to the new kernel normally (or 
returned
to firmware like we do on powernv).

Cheers,
Ben.


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

Re: [PATCH] powerpc, kexec: Fix "Processor X is stuck" issue during kexec from ST mode

2014-06-03 Thread Srivatsa S. Bhat
On 05/28/2014 07:01 PM, Vivek Goyal wrote:
> On Tue, May 27, 2014 at 04:25:34PM +0530, Srivatsa S. Bhat wrote:
>> If we try to perform a kexec when the machine is in ST (Single-Threaded) mode
>> (ppc64_cpu --smt=off), the kexec operation doesn't succeed properly, and we
>> get the following messages during boot:
>>
>> [0.089866] POWER8 performance monitor hardware support registered
>> [0.089985] power8-pmu: PMAO restore workaround active.
>> [5.095419] Processor 1 is stuck.
>> [   10.097933] Processor 2 is stuck.
>> [   15.100480] Processor 3 is stuck.
>> [   20.102982] Processor 4 is stuck.
>> [   25.105489] Processor 5 is stuck.
>> [   30.108005] Processor 6 is stuck.
>> [   35.110518] Processor 7 is stuck.
>> [   40.113369] Processor 9 is stuck.
>> [   45.115879] Processor 10 is stuck.
>> [   50.118389] Processor 11 is stuck.
>> [   55.120904] Processor 12 is stuck.
>> [   60.123425] Processor 13 is stuck.
>> [   65.125970] Processor 14 is stuck.
>> [   70.128495] Processor 15 is stuck.
>> [   75.131316] Processor 17 is stuck.
>>
>> Note that only the sibling threads are stuck, while the primary threads (0, 
>> 8,
>> 16 etc) boot just fine. Looking closer at the previous step of kexec, we 
>> observe
>> that kexec tries to wakeup (bring online) the sibling threads of all the 
>> cores,
>> before performing kexec:
>>
>> [ 9464.131231] Starting new kernel
>> [ 9464.148507] kexec: Waking offline cpu 1.
>> [ 9464.148552] kexec: Waking offline cpu 2.
>> [ 9464.148600] kexec: Waking offline cpu 3.
>> [ 9464.148636] kexec: Waking offline cpu 4.
>> [ 9464.148671] kexec: Waking offline cpu 5.
>> [ 9464.148708] kexec: Waking offline cpu 6.
>> [ 9464.148743] kexec: Waking offline cpu 7.
>> [ 9464.148779] kexec: Waking offline cpu 9.
>> [ 9464.148815] kexec: Waking offline cpu 10.
>> [ 9464.148851] kexec: Waking offline cpu 11.
>> [ 9464.148887] kexec: Waking offline cpu 12.
>> [ 9464.148922] kexec: Waking offline cpu 13.
>> [ 9464.148958] kexec: Waking offline cpu 14.
>> [ 9464.148994] kexec: Waking offline cpu 15.
>> [ 9464.149030] kexec: Waking offline cpu 17.
>>
>> Instrumenting this piece of code revealed that the cpu_up() operation 
>> actually
>> fails with -EBUSY. Thus, only the primary threads of all the cores are online
>> during kexec, and hence this is a sure-shot receipe for disaster, as 
>> explained
>> in commit e8e5c2155b (powerpc/kexec: Fix orphaned offline CPUs across kexec),
>> as well as in the comment above wake_offline_cpus().
>>
>> It turns out that cpu_up() was returning -EBUSY because the variable
>> 'cpu_hotplug_disabled' was set to 1; and this disabling of CPU hotplug was 
>> done
>> by migrate_to_reboot_cpu() inside kernel_kexec().
>>
>> Now, migrate_to_reboot_cpu() was originally written with the assumption that
>> any further code will not need to perform CPU hotplug, since we are anyway in
>> the reboot path. However, kexec is clearly not such a case, since we depend 
>> on
>> onlining CPUs, atleast on powerpc.
>>
>> So re-enable cpu-hotplug after returning from migrate_to_reboot_cpu() in the
>> kexec path, to fix this regression in kexec on powerpc.
>>
>> Also, wrap the cpu_up() in powerpc kexec code within a WARN_ON(), so that we
>> can catch such issues more easily in the future.
>>
>> Fixes: c97102ba963 (kexec: migrate to reboot cpu)
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Srivatsa S. Bhat 
>> ---
>>
>>  arch/powerpc/kernel/machine_kexec_64.c |2 +-
>>  kernel/kexec.c |8 
>>  2 files changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kernel/machine_kexec_64.c 
>> b/arch/powerpc/kernel/machine_kexec_64.c
>> index 59d229a..879b3aa 100644
>> --- a/arch/powerpc/kernel/machine_kexec_64.c
>> +++ b/arch/powerpc/kernel/machine_kexec_64.c
>> @@ -237,7 +237,7 @@ static void wake_offline_cpus(void)
>>  if (!cpu_online(cpu)) {
>>  printk(KERN_INFO "kexec: Waking offline cpu %d.\n",
>> cpu);
>> -cpu_up(cpu);
>> +WARN_ON(cpu_up(cpu));
>>  }
>>  }
>>  }
>> diff --git a/kernel/kexec.c b/kernel/kexec.c
>> index c8380ad..28c5706 100644
>> --- a/kernel/kexec.c
>> +++ b/kernel/kexec.c
>> @@ -1683,6 +1683,14 @@ int kernel_kexec(void)
>>  kexec_in_progress = true;
>>  kernel_restart_prepare(NULL);
>>  migrate_to_reboot_cpu();
>> +
>> +/*
>> + * migrate_to_reboot_cpu() disables CPU hotplug assuming that
>> + * no further code needs to use CPU hotplug (which is true in
>> + * the reboot case). However, the kexec path depends on using
>> + * CPU hotplug again; so re-enable it here.
>> + */
>> +cpu_hotplug_enable();
>>  printk(KERN_EMERG "Starting new kernel\n");
>>  machine_shutdown();
> 
> After migrate_to_reboot_cpu(), we are calling machine_shutdown() which
> calls di

Re: FMD15 and t104x

2014-06-03 Thread Scott Wood
On Tue, 2014-06-03 at 12:13 +0530, Tony wrote:
> Hi,
> 
> I am working with 3.0.x kernel with fmd15. I could bringup the
> t1040qsd but the ethernet is not getting detected. Is t104x devices
> required backporting of FMD19 ? OR modifying the dts file is enough ?

Please use supp...@freescale.com or https://community.freescale.com/ for
support of the QorIQ SDK.

That said, I'm pretty sure the FMan code from any 3.0-based SDK will not
work with t1040.

-Scott



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

Re: [PATCH] powerpc/85xx: Add T4240RDB board support

2014-06-03 Thread Scott Wood
On Tue, 2014-06-03 at 16:57 +0800, Chunhe Lan wrote:
> On 05/31/2014 05:25 AM, Scott Wood wrote:
> > On Wed, 2014-05-28 at 16:11 +0800, Chunhe Lan wrote:
> >> diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c 
> >> b/arch/powerpc/platforms/85xx/corenet_generic.c
> >> index 8e4b1e1..2f50526 100644
> >> --- a/arch/powerpc/platforms/85xx/corenet_generic.c
> >> +++ b/arch/powerpc/platforms/85xx/corenet_generic.c
> >> @@ -119,6 +119,7 @@ static const char * const boards[] __initconst = {
> >>"fsl,P5020DS",
> >>"fsl,P5040DS",
> >>"fsl,T4240QDS",
> >> +  "fsl,T4240RDB",
> >>"fsl,B4860QDS",
> >>"fsl,B4420QDS",
> >>"fsl,B4220QDS",
> > What about hv_boards?
>  Does not have hv boards. So does not support hv.

This isn't about a physical "hv board".  Topaz appends -hv to the board
compatible.  I wish we had just made a single "Topaz e500 platform" like
we did for qemu e500, but oh well.

-Scott


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

Re: [PATCH v2] powerpc/booke64: wrap tlb lock and search in htw miss with FTR_SMT

2014-06-03 Thread Tudor Laurentiu

On 06/02/2014 07:45 PM, Scott Wood wrote:

On Mon, 2014-06-02 at 15:48 +0300, Tudor Laurentiu wrote:

On 05/31/2014 01:45 AM, Scott Wood wrote:

From: Laurentiu Tudor 
   - resent since the original didn't make it to the list archives
 or patchwork.


The only thing i can think of is that maybe i've misspelled the mailing
list address ...


It looks right to me.  Did you get a bounce?



Strangely, no. I'm out of ideas.

---
Best Regards, Laurentiu


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

[PATCH] KVM: PPC: BOOK3S: PR: Fix PURR and SPURR emulation

2014-06-03 Thread Aneesh Kumar K.V
We use time base for PURR and SPURR emulation with PR KVM since we
are emulating a single threaded core. When using time base
we need to make sure that we don't accumulate time spent in the host
in PURR and SPURR value.

Also we don't need to emulate mtspr because both the registers are
hypervisor resource.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/kvm_book3s.h |  2 --
 arch/powerpc/include/asm/kvm_host.h   |  4 ++--
 arch/powerpc/kvm/book3s_emulate.c | 16 
 arch/powerpc/kvm/book3s_pr.c  | 10 ++
 4 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_book3s.h 
b/arch/powerpc/include/asm/kvm_book3s.h
index f52f65694527..a20cc0bbd048 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -83,8 +83,6 @@ struct kvmppc_vcpu_book3s {
u64 sdr1;
u64 hior;
u64 msr_mask;
-   u64 purr_offset;
-   u64 spurr_offset;
 #ifdef CONFIG_PPC_BOOK3S_32
u32 vsid_pool[VSID_POOL_SIZE];
u32 vsid_next;
diff --git a/arch/powerpc/include/asm/kvm_host.h 
b/arch/powerpc/include/asm/kvm_host.h
index bb66d8b8efdf..4a58731a0a72 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -503,8 +503,8 @@ struct kvm_vcpu_arch {
 #ifdef CONFIG_BOOKE
u32 decar;
 #endif
-   u32 tbl;
-   u32 tbu;
+   /* Time base value when we entered the guest */
+   u64 entry_tb;
u32 tcr;
ulong tsr; /* we need to perform set/clr_bits() which requires ulong */
u32 ivor[64];
diff --git a/arch/powerpc/kvm/book3s_emulate.c 
b/arch/powerpc/kvm/book3s_emulate.c
index 3f295269af37..3565e775b61b 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -439,12 +439,6 @@ int kvmppc_core_emulate_mtspr_pr(struct kvm_vcpu *vcpu, 
int sprn, ulong spr_val)
(mfmsr() & MSR_HV))
vcpu->arch.hflags |= BOOK3S_HFLAG_DCBZ32;
break;
-   case SPRN_PURR:
-   to_book3s(vcpu)->purr_offset = spr_val - get_tb();
-   break;
-   case SPRN_SPURR:
-   to_book3s(vcpu)->spurr_offset = spr_val - get_tb();
-   break;
case SPRN_GQR0:
case SPRN_GQR1:
case SPRN_GQR2:
@@ -572,10 +566,16 @@ int kvmppc_core_emulate_mfspr_pr(struct kvm_vcpu *vcpu, 
int sprn, ulong *spr_val
*spr_val = 0;
break;
case SPRN_PURR:
-   *spr_val = get_tb() + to_book3s(vcpu)->purr_offset;
+   /*
+* On exit we would have updated purr
+*/
+   *spr_val = vcpu->arch.purr;
break;
case SPRN_SPURR:
-   *spr_val = get_tb() + to_book3s(vcpu)->purr_offset;
+   /*
+* On exit we would have updated spurr
+*/
+   *spr_val = vcpu->arch.spurr;
break;
case SPRN_GQR0:
case SPRN_GQR1:
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 23367a7e44c3..c71ce784a72f 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -121,6 +121,11 @@ void kvmppc_copy_to_svcpu(struct kvmppc_book3s_shadow_vcpu 
*svcpu,
svcpu->shadow_fscr = vcpu->arch.shadow_fscr;
 #endif
svcpu->in_use = true;
+   /*
+* Now also save the current time base value. We use this
+* to find the guest purr and spurr value.
+*/
+   vcpu->arch.entry_tb = get_tb();
 }
 
 /* Copy data touched by real-mode code from shadow vcpu back to vcpu */
@@ -170,6 +175,11 @@ void kvmppc_copy_from_svcpu(struct kvm_vcpu *vcpu,
 
 out:
preempt_enable();
+   /*
+* Update purr and spurr using time base
+*/
+   vcpu->arch.purr += get_tb() - vcpu->arch.entry_tb;
+   vcpu->arch.spurr += get_tb() - vcpu->arch.entry_tb;
 }
 
 static int kvmppc_core_check_requests_pr(struct kvm_vcpu *vcpu)
-- 
1.9.1

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

[PATCH v3] powerpc/85xx: Add T4240RDB board support

2014-06-03 Thread Chunhe Lan
T4240RDB board Specification

Memory subsystem:
 6GB DDR3
 128MB NOR flash
 2GB NAND flash
Ethernet:
 Eight 1G SGMII ports
 Four 10Gbps SFP+ ports
PCIe:
 Two PCIe slots
USB:
 Two USB2.0 Type A ports
SDHC:
 One SD-card port
SATA:
 One SATA port
UART:
 Dual RJ45 ports

Signed-off-by: Chunhe Lan 
Cc: Scott Wood 
---
 arch/powerpc/boot/dts/t4240rdb.dts|  186 +
 arch/powerpc/configs/corenet64_smp_defconfig  |4 +
 arch/powerpc/platforms/85xx/Kconfig   |2 +-
 arch/powerpc/platforms/85xx/corenet_generic.c |2 +
 4 files changed, 193 insertions(+), 1 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/t4240rdb.dts

diff --git a/arch/powerpc/boot/dts/t4240rdb.dts 
b/arch/powerpc/boot/dts/t4240rdb.dts
new file mode 100644
index 000..53761d4
--- /dev/null
+++ b/arch/powerpc/boot/dts/t4240rdb.dts
@@ -0,0 +1,186 @@
+/*
+ * T4240RDB Device Tree Source
+ *
+ * Copyright 2014 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/t4240si-pre.dtsi"
+
+/ {
+   model = "fsl,T4240RDB";
+   compatible = "fsl,T4240RDB";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   interrupt-parent = <&mpic>;
+
+   ifc: localbus@ffe124000 {
+   reg = <0xf 0xfe124000 0 0x2000>;
+   ranges = <0 0 0xf 0xe800 0x0800
+ 2 0 0xf 0xff80 0x0001
+ 3 0 0xf 0xffdf 0x8000>;
+
+   nor@0,0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "cfi-flash";
+   reg = <0x0 0x0 0x800>;
+
+   bank-width = <2>;
+   device-width = <1>;
+   };
+
+   nand@2,0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,ifc-nand";
+   reg = <0x2 0x0 0x1>;
+   };
+   };
+
+   memory {
+   device_type = "memory";
+   };
+
+   dcsr: dcsr@f {
+   ranges = <0x 0xf 0x 0x01072000>;
+   };
+
+   soc: soc@ffe00 {
+   ranges = <0x 0xf 0xfe00 0x100>;
+   reg = <0xf 0xfe00 0 0x1000>;
+   spi@11 {
+   flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "sst,sst25wf040";
+   reg = <0>;
+   spi-max-frequency = <4000>; /* input clock 
*/
+   };
+   };
+
+   i2c@118000 {
+   eeprom@52 {
+   compatible = "at24,24c256";
+   reg = <0x52>;
+   };
+   eeprom@54 {
+   compatible = "at24,24c256";
+   reg = <0x54>;
+   };
+   eeprom@56 {
+  

Re: [PATCH v2] powerpc/85xx: Add T4240RDB board support

2014-06-03 Thread Chunhe Lan

On 06/03/2014 05:59 PM, Tudor Laurentiu wrote:

Hi Chunhe

Comment inline ...

On 06/03/2014 12:10 PM, Chunhe Lan wrote:




diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c 
b/arch/powerpc/platforms/85xx/corenet_generic.c

index 8e4b1e1..2f50526 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -119,6 +119,7 @@ static const char * const boards[] __initconst = {
  "fsl,P5020DS",
  "fsl,P5040DS",
  "fsl,T4240QDS",
+"fsl,T4240RDB",


T4240RDB is supported & tested under hypervisor so please also add the 
hypervisor compatible in the "hv_boards" array below.


 I never use under hypervisor of T4240RDB. Thank you that you 
provide this information.

 I will add T4240RDB hv support.

Thanks,
-Chunhe

---
Thanks & Best Regards, Laurentiu



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

[PATCH] powerpc/powernv: Provide debugfs access to the LPC bus via OPAL

2014-06-03 Thread Benjamin Herrenschmidt
This provides debugfs files to access the LPC bus on Power8
non-virtualized using the appropriate OPAL firmware calls.

The usage is simple: one file per space (IO, MEM and FW),
lseek to the address and read/write the data. IO and MEM always
generate series of byte accesses. FW can generate word and dword
accesses if aligned properly.

Based on an original patch from Rob Lippert and reworked.

Signed-off-by: Benjamin Herrenschmidt 
---
 arch/powerpc/platforms/powernv/opal-lpc.c |  150 +
 1 file changed, 150 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/opal-lpc.c 
b/arch/powerpc/platforms/powernv/opal-lpc.c
index 79d83ca..70eff22 100644
--- a/arch/powerpc/platforms/powernv/opal-lpc.c
+++ b/arch/powerpc/platforms/powernv/opal-lpc.c
@@ -12,12 +12,16 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 static int opal_lpc_chip_id = -1;
 
@@ -176,6 +180,152 @@ static const struct ppc_pci_io opal_lpc_io = {
.outsl  = opal_lpc_outsl,
 };
 
+#ifdef CONFIG_DEBUG_FS
+struct lpc_debugfs_entry {
+   enum OpalLPCAddressType lpc_type;
+};
+
+static ssize_t lpc_debug_read(struct file *filp, char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+   struct lpc_debugfs_entry *lpc = filp->private_data;
+   u32 data, pos, len, todo;
+   int rc;
+
+   if (!access_ok(VERIFY_WRITE, ubuf, count))
+   return -EFAULT;
+
+   todo = count;
+   while (todo) {
+   pos = *ppos;
+
+   /*
+* Select access size based on count and alignment and
+* access type. IO and MEM only support byte acceses,
+* FW supports all 3.
+*/
+   len = 1;
+   if (lpc->lpc_type == OPAL_LPC_FW) {
+   if (todo > 3 && (pos & 3) == 0)
+   len = 4;
+   else if (todo > 1 && (pos & 1) == 0)
+   len = 2;
+   }
+   rc = opal_lpc_read(opal_lpc_chip_id, lpc->lpc_type, pos,
+  &data, len);
+   if (rc)
+   return -ENXIO;
+   switch(len) {
+   case 4:
+   rc = __put_user((u32)data, (u32 __user *)ubuf);
+   break;
+   case 2:
+   rc = __put_user((u16)data, (u16 __user *)ubuf);
+   break;
+   default:
+   rc = __put_user((u8)data, (u8 __user *)ubuf);
+   break;
+   }
+   if (rc)
+   return -EFAULT;
+   *ppos += len;
+   ubuf += len;
+   todo -= len;
+   }
+
+   return count;
+}
+
+static ssize_t lpc_debug_write(struct file *filp, const char __user *ubuf,
+  size_t count, loff_t *ppos)
+{
+   struct lpc_debugfs_entry *lpc = filp->private_data;
+   u32 data, pos, len, todo;
+   int rc;
+
+   if (!access_ok(VERIFY_READ, ubuf, count))
+   return -EFAULT;
+
+   todo = count;
+   while (todo) {
+   pos = *ppos;
+
+   /*
+* Select access size based on count and alignment and
+* access type. IO and MEM only support byte acceses,
+* FW supports all 3.
+*/
+   len = 1;
+   if (lpc->lpc_type == OPAL_LPC_FW) {
+   if (todo > 3 && (pos & 3) == 0)
+   len = 4;
+   else if (todo > 1 && (pos & 1) == 0)
+   len = 2;
+   }
+   switch(len) {
+   case 4:
+   rc = __get_user(data, (u32 __user *)ubuf);
+   break;
+   case 2:
+   rc = __get_user(data, (u16 __user *)ubuf);
+   break;
+   default:
+   rc = __get_user(data, (u8 __user *)ubuf);
+   break;
+   }
+   if (rc)
+   return -EFAULT;
+
+   rc = opal_lpc_write(opal_lpc_chip_id, lpc->lpc_type, pos,
+   data, len);
+   if (rc)
+   return -ENXIO;
+   *ppos += len;
+   ubuf += len;
+   todo -= len;
+   }
+
+   return count;
+}
+
+static const struct file_operations lpc_fops = {
+   .read = lpc_debug_read,
+   .write =lpc_debug_write,
+   .open = simple_open,
+   .llseek =   default_llseek,
+};
+
+static int opal_lpc_debugfs_create_type(struct dentry *folder,
+   const char *fname,
+   enum O

Re: [PATCH v2] powerpc/85xx: Add T4240RDB board support

2014-06-03 Thread Tudor Laurentiu

Hi Chunhe

Comment inline ...

On 06/03/2014 12:10 PM, Chunhe Lan wrote:

T4240RDB board Specification

Memory subsystem:
  6GB DDR3
  128MB NOR flash
  2GB NAND flash
Ethernet:
  Eight 1G SGMII ports
  Four 10Gbps SFP+ ports
PCIe:
  Two PCIe slots
USB:
  Two USB2.0 Type A ports
SDHC:
  One SD-card port
SATA:
  One SATA port
UART:
  Dual RJ45 ports

Signed-off-by: Chunhe Lan 
Cc: Scott Wood 
---


[snip]



diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c 
b/arch/powerpc/platforms/85xx/corenet_generic.c
index 8e4b1e1..2f50526 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -119,6 +119,7 @@ static const char * const boards[] __initconst = {
"fsl,P5020DS",
"fsl,P5040DS",
"fsl,T4240QDS",
+   "fsl,T4240RDB",


T4240RDB is supported & tested under hypervisor so please also add the 
hypervisor compatible in the "hv_boards" array below.


---
Thanks & Best Regards, Laurentiu
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 3/3] PPC, KVM, CMA: use general CMA reserved area management framework

2014-06-03 Thread Paolo Bonzini

Il 03/06/2014 09:02, Michal Nazarewicz ha scritto:

On Tue, Jun 03 2014, Joonsoo Kim wrote:

Now, we have general CMA reserved area management framework,
so use it for future maintainabilty. There is no functional change.

Signed-off-by: Joonsoo Kim 


Acked-by: Michal Nazarewicz 



Acked-by: Paolo Bonzini 

Aneesh, can you test this series?

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

[PATCH v2] powerpc/85xx: Add T4240RDB board support

2014-06-03 Thread Chunhe Lan
T4240RDB board Specification

Memory subsystem:
 6GB DDR3
 128MB NOR flash
 2GB NAND flash
Ethernet:
 Eight 1G SGMII ports
 Four 10Gbps SFP+ ports
PCIe:
 Two PCIe slots
USB:
 Two USB2.0 Type A ports
SDHC:
 One SD-card port
SATA:
 One SATA port
UART:
 Dual RJ45 ports

Signed-off-by: Chunhe Lan 
Cc: Scott Wood 
---
 arch/powerpc/boot/dts/t4240rdb.dts|  186 +
 arch/powerpc/configs/corenet64_smp_defconfig  |4 +
 arch/powerpc/platforms/85xx/Kconfig   |2 +-
 arch/powerpc/platforms/85xx/corenet_generic.c |1 +
 4 files changed, 192 insertions(+), 1 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/t4240rdb.dts

diff --git a/arch/powerpc/boot/dts/t4240rdb.dts 
b/arch/powerpc/boot/dts/t4240rdb.dts
new file mode 100644
index 000..53761d4
--- /dev/null
+++ b/arch/powerpc/boot/dts/t4240rdb.dts
@@ -0,0 +1,186 @@
+/*
+ * T4240RDB Device Tree Source
+ *
+ * Copyright 2014 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/t4240si-pre.dtsi"
+
+/ {
+   model = "fsl,T4240RDB";
+   compatible = "fsl,T4240RDB";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   interrupt-parent = <&mpic>;
+
+   ifc: localbus@ffe124000 {
+   reg = <0xf 0xfe124000 0 0x2000>;
+   ranges = <0 0 0xf 0xe800 0x0800
+ 2 0 0xf 0xff80 0x0001
+ 3 0 0xf 0xffdf 0x8000>;
+
+   nor@0,0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "cfi-flash";
+   reg = <0x0 0x0 0x800>;
+
+   bank-width = <2>;
+   device-width = <1>;
+   };
+
+   nand@2,0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,ifc-nand";
+   reg = <0x2 0x0 0x1>;
+   };
+   };
+
+   memory {
+   device_type = "memory";
+   };
+
+   dcsr: dcsr@f {
+   ranges = <0x 0xf 0x 0x01072000>;
+   };
+
+   soc: soc@ffe00 {
+   ranges = <0x 0xf 0xfe00 0x100>;
+   reg = <0xf 0xfe00 0 0x1000>;
+   spi@11 {
+   flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "sst,sst25wf040";
+   reg = <0>;
+   spi-max-frequency = <4000>; /* input clock 
*/
+   };
+   };
+
+   i2c@118000 {
+   eeprom@52 {
+   compatible = "at24,24c256";
+   reg = <0x52>;
+   };
+   eeprom@54 {
+   compatible = "at24,24c256";
+   reg = <0x54>;
+   };
+   eeprom@56 {
+  

Re: [PATCH] powerpc/85xx: Add T4240RDB board support

2014-06-03 Thread Chunhe Lan

On 05/31/2014 05:25 AM, Scott Wood wrote:

On Wed, 2014-05-28 at 16:11 +0800, Chunhe Lan wrote:

diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c 
b/arch/powerpc/platforms/85xx/corenet_generic.c
index 8e4b1e1..2f50526 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -119,6 +119,7 @@ static const char * const boards[] __initconst = {
"fsl,P5020DS",
"fsl,P5040DS",
"fsl,T4240QDS",
+   "fsl,T4240RDB",
"fsl,B4860QDS",
"fsl,B4420QDS",
"fsl,B4220QDS",

What about hv_boards?

Does not have hv boards. So does not support hv.

Thanks,
-Chunhe


-Scott





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

Re: [PATCH] powerpc, xmon: Enable hardware instruction breakpoint support on POWER8

2014-06-03 Thread Anshuman Khandual
On 06/02/2014 02:18 PM, Anshuman Khandual wrote:
> On 06/01/2014 11:48 AM, Michael Neuling wrote:
>> > On Fri, 2014-05-30 at 17:40 +0530, Anshuman Khandual wrote:
>>> >> This patch enables support for hardware instruction breakpoints on 
>>> >> POWER8 with
>>> >> the help of a new register called CIABR (Completed Instruction Address 
>>> >> Breakpoint
>>> >> Register). With this patch, single hardware instruction breakpoint can 
>>> >> be added
>>> >> and cleared during any active xmon debug session. This hardware based 
>>> >> instruction
>>> >> breakpoint mechanism works correctly along with the existing TRAP based 
>>> >> instruction
>>> >> breakpoints available on xmon. Example usage as follows.
>> > 
>> > Have you actually tried this on a guest?
>> > 
> Yeah on a guest which runs on PVM.
> 
>> > Please also compile with a range of configs.  It doesn't compile with
>> > ppc64e_defconfig.
> Yeah. Need to change the way we get the "plapr_set_ciabr" function from 
> plpar_wrappers.h
> header file. Will add this hunk of code in "xmon.h" header and remove the 
> CONFIG_PPC64 ifdef
> code from the function write_ciabr.
> 
> +#ifdef CONFIG_PPC_BOOK3S_64

"#if defined(CONFIG_PPC_BOOK3S_64) && defined(CONFIG_PPC_SPLPAR)" here actually 
makes it build
on all these configurations listed below.

pseries_defconfig
ppc64_defconfig
ppc64e_defconfig
pmac32_defconfig
ppc44x_defconfig
ppc6xx_defconfig
mpc85xx_smp_defconfig
mpc85xx_defconfig
chroma_defconfig
ps3_defconfig
celleb_defconfig
allnoconfig

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

Re: [PATCH 4/4] powerpc/eeh: Avoid event on passed PE

2014-06-03 Thread Benjamin Herrenschmidt
On Tue, 2014-06-03 at 09:45 +0200, Alexander Graf wrote:
> For EEH it could as well be a dumb eventfd - really just a side
> channel that can tell user space that something happened
> asynchronously :).

Which the host kernel may have no way to detect without actively poking
at the device (fences in powernv or anything in PAPR host) and the only
user of this for now has no use for.

I insist don't bother.

Cheers,
Ben.


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

FMD15 and t104x

2014-06-03 Thread Tony
Hi,

I am working with 3.0.x kernel with fmd15. I could bringup the t1040qsd but
the ethernet is not getting detected. Is t104x devices required backporting
of FMD19 ? OR modifying the dts file is enough ?

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

Re: [PATCH 4/4] powerpc/eeh: Avoid event on passed PE

2014-06-03 Thread Alexander Graf


> Am 03.06.2014 um 07:54 schrieb Paul Mackerras :
> 
>> On Tue, May 20, 2014 at 01:25:11PM +0200, Alexander Graf wrote:
>> 
>>> On 20.05.14 10:30, Gavin Shan wrote:
>>> If we detects frozen state on PE that has been passed to guest, we
>>> needn't handle it. Instead, we rely on the guest to detect and recover
>>> it. The patch avoid EEH event on the frozen passed PE so that the guest
>>> can have chance to handle that.
>>> 
>>> Signed-off-by: Gavin Shan 
>> 
>> How does the guest learn about this failure? We'd need to inject an error
>> into it, no?
>> 
>> I think what you want is an irqfd that the in-kernel eeh code notifies when
>> it sees a failure. When such an fd exists, the kernel skips its own error
>> handling.
> 
> Well... we don't have irqfd support for book3s HV upstream yet.  The
> way the current code is, we have to turn on GSI routing, which puts a
> hard and relatively small limit on the hardware IRQ numbers we can use
> as it uses a flat array indexed by hardware IRQ number.  Which is a
> problem that I need to solve somehow,

Please sync up with the ARM folks on this - they were also unhappy about the 
routing requirements for irqfd ;).

> but it makes using an irqfd
> unattractive in the short term.

For EEH it could as well be a dumb eventfd - really just a side channel that 
can tell user space that something happened asynchronously :).


Alex

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

[PATCH] powerpc/serial: Use saner flags when creating legacy ports

2014-06-03 Thread Benjamin Herrenschmidt
From 6679ffd7d85fe8155172774d0ba3370be5e82d1d Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt 
Date: Sat, 29 Mar 2014 08:38:36 +1100
Subject: 

We had a mix & match of flags used when creating legacy ports
depending on where we found them in the device-tree. Among others
we were missing UPF_SKIP_TEST for some kind of ISA ports which is
a problem as quite a few UARTs out there don't support the loopback
test (such as a lot of BMCs).

Let's pick the set of flags used by the SoC code and generalize it
which means autoconf, no loopback test, irq maybe shared and fixed
port.

Sending to stable as the lack of UPF_SKIP_TEST is breaking
serial on some machines so I want this back into distros

Signed-off-by: Benjamin Herrenschmidt 
CC: sta...@vger.kernel.org
---
 arch/powerpc/kernel/legacy_serial.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/legacy_serial.c 
b/arch/powerpc/kernel/legacy_serial.c
index 6f2a15c..085c919 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -48,6 +48,9 @@ static struct __initdata of_device_id legacy_serial_parents[] 
= {
 static unsigned int legacy_serial_count;
 static int legacy_serial_console = -1;
 
+static const upf_t legacy_port_flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
+   UPF_SHARE_IRQ | UPF_FIXED_PORT;
+
 static unsigned int tsi_serial_in(struct uart_port *p, int offset)
 {
unsigned int tmp;
@@ -153,8 +156,6 @@ static int __init add_legacy_soc_port(struct device_node 
*np,
 {
u64 addr;
const u32 *addrp;
-   upf_t flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_SHARE_IRQ
-   | UPF_FIXED_PORT;
struct device_node *tsi = of_get_parent(np);
 
/* We only support ports that have a clock frequency properly
@@ -185,9 +186,11 @@ static int __init add_legacy_soc_port(struct device_node 
*np,
 * IO port value. It will be fixed up later along with the irq
 */
if (tsi && !strcmp(tsi->type, "tsi-bridge"))
-   return add_legacy_port(np, -1, UPIO_TSI, addr, addr, NO_IRQ, 
flags, 0);
+   return add_legacy_port(np, -1, UPIO_TSI, addr, addr,
+  NO_IRQ, legacy_port_flags, 0);
else
-   return add_legacy_port(np, -1, UPIO_MEM, addr, addr, NO_IRQ, 
flags, 0);
+   return add_legacy_port(np, -1, UPIO_MEM, addr, addr,
+  NO_IRQ, legacy_port_flags, 0);
 }
 
 static int __init add_legacy_isa_port(struct device_node *np,
@@ -233,7 +236,7 @@ static int __init add_legacy_isa_port(struct device_node 
*np,
 
/* Add port, irq will be dealt with later */
return add_legacy_port(np, index, UPIO_PORT, be32_to_cpu(reg[1]),
-  taddr, NO_IRQ, UPF_BOOT_AUTOCONF, 0);
+  taddr, NO_IRQ, legacy_port_flags, 0);
 
 }
 
@@ -306,7 +309,7 @@ static int __init add_legacy_pci_port(struct device_node 
*np,
 * IO port value. It will be fixed up later along with the irq
 */
return add_legacy_port(np, index, iotype, base, addr, NO_IRQ,
-  UPF_BOOT_AUTOCONF, np != pci_dev);
+  legacy_port_flags, np != pci_dev);
 }
 #endif
 


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

Re: [RFC PATCH 3/3] PPC, KVM, CMA: use general CMA reserved area management framework

2014-06-03 Thread Michal Nazarewicz
On Tue, Jun 03 2014, Joonsoo Kim wrote:
> Now, we have general CMA reserved area management framework,
> so use it for future maintainabilty. There is no functional change.
>
> Signed-off-by: Joonsoo Kim 

Acked-by: Michal Nazarewicz 

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 2/3] DMA, CMA: use general CMA reserved area management framework

2014-06-03 Thread Michal Nazarewicz
On Tue, Jun 03 2014, Joonsoo Kim wrote:
> Now, we have general CMA reserved area management framework,
> so use it for future maintainabilty. There is no functional change.
>
> Signed-off-by: Joonsoo Kim 

Acked-by: Michal Nazarewicz 

> diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
> index dfb1dc9..ecb85ac 100644
> --- a/include/linux/dma-contiguous.h
> +++ b/include/linux/dma-contiguous.h
> @@ -53,9 +53,10 @@
>  
>  #ifdef __KERNEL__
>  
> +#include 
> +

Why is this suddenly required?

>  struct cma;
>  struct page;
> -struct device;
>  
>  #ifdef CONFIG_DMA_CMA

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev