[PATCH] powerpc/hw_breakpoints: Add DABRX cpu feature

2013-05-17 Thread Michael Neuling 
Some CPUs have a DABR but not DABRX.  Configuration are:
- No 32bit CPUs have DABRX but some have DABR.
- POWER4+ and below have the DABR but no DABRX.
- 970 and POWER5 and above have DABR and DABRX.
- POWER8 has DAWR, hence no DABRX.

This introduces CPU_FTR_DABRX and sets it on appropriate CPUs.  We use
the top 64 bits for CPU FTR bits since only 64 bit CPUs have this.

Processors that don't have the DABRX will still work as they will fall
back to software filtering these breakpoints via perf_exclude_event().

Signed-off-by: Michael Neuling mi...@neuling.org
Reported-by: Gorelik, Jacob (335F) jacob.gore...@jpl.nasa.gov
cc: sta...@vger.kernel.org (v3.9 only)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 26807e5..6f3887d 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -176,6 +176,7 @@ extern const char *powerpc_base_platform;
 #define CPU_FTR_CFAR   LONG_ASM_CONST(0x0100)
 #defineCPU_FTR_HAS_PPR 
LONG_ASM_CONST(0x0200)
 #define CPU_FTR_DAWR   LONG_ASM_CONST(0x0400)
+#define CPU_FTR_DABRX  LONG_ASM_CONST(0x0800)
 
 #ifndef __ASSEMBLY__
 
@@ -394,19 +395,20 @@ extern const char *powerpc_base_platform;
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | CPU_FTR_ARCH_201 | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA | \
CPU_FTR_CP_USE_DCBTZ | CPU_FTR_STCX_CHECKS_ADDRESS | \
-   CPU_FTR_HVMODE)
+   CPU_FTR_HVMODE | CPU_FTR_DABRX)
 #define CPU_FTRS_POWER5(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_PURR | \
-   CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB)
+   CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_DABRX)
 #define CPU_FTRS_POWER6 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | \
CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
CPU_FTR_DSCR | CPU_FTR_UNALIGNED_LD_STD | \
-   CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_CFAR)
+   CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_CFAR | \
+   CPU_FTR_DABRX)
 #define CPU_FTRS_POWER7 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | CPU_FTR_ARCH_206 |\
CPU_FTR_MMCRA | CPU_FTR_SMT | \
@@ -415,7 +417,7 @@ extern const char *powerpc_base_platform;
CPU_FTR_DSCR | CPU_FTR_SAO  | CPU_FTR_ASYM_SMT | \
CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
CPU_FTR_ICSWX | CPU_FTR_CFAR | CPU_FTR_HVMODE | \
-   CPU_FTR_VMX_COPY | CPU_FTR_HAS_PPR)
+   CPU_FTR_VMX_COPY | CPU_FTR_HAS_PPR | CPU_FTR_DABRX)
 #define CPU_FTRS_POWER8 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | CPU_FTR_ARCH_206 |\
CPU_FTR_MMCRA | CPU_FTR_SMT | \
@@ -430,14 +432,15 @@ extern const char *powerpc_base_platform;
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_PAUSE_ZERO  | CPU_FTR_CELL_TB_BUG | CPU_FTR_CP_USE_DCBTZ | \
-   CPU_FTR_UNALIGNED_LD_STD)
+   CPU_FTR_UNALIGNED_LD_STD | CPU_FTR_DABRX)
 #define CPU_FTRS_PA6T (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_ALTIVEC_COMP | \
-   CPU_FTR_PURR | CPU_FTR_REAL_LE)
+   CPU_FTR_PURR | CPU_FTR_REAL_LE | CPU_FTR_DABRX)
 #define CPU_FTRS_COMPATIBLE(CPU_FTR_USE_TB | CPU_FTR_PPCAS_ARCH_V2)
 
 #define CPU_FTRS_A2 (CPU_FTR_USE_TB | CPU_FTR_SMT | CPU_FTR_DBELL | \
-CPU_FTR_NOEXECUTE | CPU_FTR_NODSISRALIGN | CPU_FTR_ICSWX)
+CPU_FTR_NOEXECUTE | CPU_FTR_NODSISRALIGN | \
+CPU_FTR_ICSWX | CPU_FTR_DABRX )
 
 #ifdef __powerpc64__
 #ifdef CONFIG_PPC_BOOK3E
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index a902723..b0f3e3f 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -399,7 +399,8 @@ static inline int __set_dabr(unsigned long dabr, unsigned 
long dabrx)
 static inline int __set_dabr(unsigned long dabr, unsigned long dabrx)
 {
mtspr(SPRN_DABR, dabr);
-   mtspr(SPRN_DABRX, dabrx);
+   if (cpu_has_feature(CPU_FTR_DABRX))
+   mtspr(SPRN_DABRX, dabrx);
return 0;
 }
 #else
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] powerpc/512x: DMA via LocalPlus Bus testing driver

2013-05-17 Thread Alexander Popov 
2013/5/17 Greg Kroah-Hartman gre...@linuxfoundation.org:
 On Thu, May 02, 2013 at 07:23:15PM +0400, Alexander Popov wrote:
 This module tests Direct Memory Access to some device on LocalPlus Bus
 for Freescale MPC512x. In other words it tests the bundle
 of mpc512x_lpbfifo and mpc512x_dma drivers.

 This testing driver was multiply used with static RAM (CY62167EV30LL-45ZXI)
 which lives on LocalPlus Bus on our board. This testing driver was used
 instead of the original static RAM driver and it is an abnormal hack.
 That is why I just provide the driver code and don't modify any environment.


 You obviously didn't test your testing driver to see if it would build
 in the kernel source tree :(

 Care to try again?

Hello Greg,
thanks for your comment.

You are right, this testing driver will not be built in the kernel source tree,
because I intentionally didn't send patches for the corresponding
Makefile, Kconfig and dts.

I would try to explain the reason once again:

I multiply used this testing driver with static RAM (CY62167EV30LL-45ZXI)
to test mpc512x_lpbfifo driver (which is [PATCH 1/2]:
https://patchwork.kernel.org/patch/2511941/ ).
I used this testing driver _instead_ of the original static RAM driver
and it is an abnormal hack.
Because it breaks the usual work of static RAM.
That's why I just provided the code of this testing driver and didn't
modify Makefile, Kconfig and dts.

I hoped that the code of this testing driver will help to review
mpc512x_lpbfifo in the first part of this patch.
Thanks.

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

[PATCH 0/2] two minor cleanup patches for function pci_process_bridge_OF_ranges

2013-05-17 Thread Kevin Hao 

Kevin Hao (2):
  powerpc/pci: remove the stale comments of pci_process_bridge_OF_ranges
  powerpc/pci: remove the unused variables in
pci_process_bridge_OF_ranges

 arch/powerpc/kernel/pci-common.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

-- 
1.8.1.4

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

[PATCH 1/2] powerpc/pci: remove the stale comments of pci_process_bridge_OF_ranges

2013-05-17 Thread Kevin Hao 
These comments already don't apply to the current code. So just remove
them.

Signed-off-by: Kevin Hao haoke...@gmail.com
---
 arch/powerpc/kernel/pci-common.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 6053f03..8245d51 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -657,15 +657,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int 
bar,
  * ranges. However, some machines (thanks Apple !) tend to split their
  * space into lots of small contiguous ranges. So we have to coalesce.
  *
- *   - We can only cope with all memory ranges having the same offset
- * between CPU addresses and PCI addresses. Unfortunately, some bridges
- * are setup for a large 1:1 mapping along with a small window which
- * maps PCI address 0 to some arbitrary high address of the CPU space in
- * order to give access to the ISA memory hole.
- * The way out of here that I've chosen for now is to always set the
- * offset based on the first resource found, then override it if we
- * have a different offset and the previous was set by an ISA hole.
- *
  *   - Some busses have IO space not starting at 0, which causes trouble with
  * the way we do our IO resource renumbering. The code somewhat deals with
  * it for 64 bits but I would expect problems on 32 bits.
-- 
1.8.1.4

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

[PATCH 2/2] powerpc/pci: remove the unused variables in pci_process_bridge_OF_ranges

2013-05-17 Thread Kevin Hao 
The codes which ever used these two variables have gone. Throw away
them too.

Signed-off-by: Kevin Hao haoke...@gmail.com
---
 arch/powerpc/kernel/pci-common.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 8245d51..50fabab 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -671,10 +671,9 @@ void pci_process_bridge_OF_ranges(struct pci_controller 
*hose,
int rlen;
int pna = of_n_addr_cells(dev);
int np = pna + 5;
-   int memno = 0, isa_hole = -1;
+   int memno = 0;
u32 pci_space;
unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
-   unsigned long long isa_mb = 0;
struct resource *res;
 
printk(KERN_INFO PCI host bridge %s %s ranges:\n,
@@ -768,8 +767,6 @@ void pci_process_bridge_OF_ranges(struct pci_controller 
*hose,
}
/* Handles ISA memory hole space here */
if (pci_addr == 0) {
-   isa_mb = cpu_addr;
-   isa_hole = memno;
if (primary || isa_mem_base == 0)
isa_mem_base = cpu_addr;
hose-isa_mem_phys = cpu_addr;
-- 
1.8.1.4

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

[PATCH] powerpc/pci: fix PCI-e check link issue

2013-05-17 Thread Yuanquan Chen 
For Freescale powerpc platform, the PCI-e bus number uses the reassign mode
by default. It means the second PCI-e controller's hose-first_busno is the
first controller's last bus number adding 1. For some hotpluged device(or
controlled by FPGA), the device is linked to PCI-e slot at linux runtime.
It needs rescan for the system to add it and driver it to work. It successes
to rescan the device linked to the first PCI-e controller's slot, but fails to
rescan the device linked to the second PCI-e controller's slot. The cause is
that the bus-number is reset to 0, which isn't equal to the hose-first_busno
for the second controller checking PCI-e link. So it doesn't really check the
PCI-e link status, the link status is always no_link. The device won't be
really rescaned. Reset the bus-number to hose-first_busno in the function
fsl_pcie_check_link(), it will do the real checking PCI-e link status for the
second controller, the device will be rescaned.

Signed-off-by: Yuanquan Chen yuanquan.c...@freescale.com
---
 arch/powerpc/sysdev/fsl_pci.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 028ac1f..534597a 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -64,7 +64,7 @@ static int fsl_pcie_check_link(struct pci_controller *hose)
if (hose-indirect_type  PPC_INDIRECT_TYPE_FSL_CFG_REG_LINK) {
if (hose-ops-read == fsl_indirect_read_config) {
struct pci_bus bus;
-   bus.number = 0;
+   bus.number = hose-first_busno;
bus.sysdata = hose;
bus.ops = hose-ops;
indirect_read_config(bus, 0, PCIE_LTSSM, 4, val);
-- 
1.7.9.5


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

[PATCH 2/2] powerpc: split hugepage when using subpage protection

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

We find all the overlapping vma and mark them such that we don't allocate
hugepage in that range. Also we split existing huge page so that the
normal page hash can be invalidated and new page faulted in with new
protection bits.

Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
 arch/powerpc/mm/subpage-prot.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/powerpc/mm/subpage-prot.c b/arch/powerpc/mm/subpage-prot.c
index 7c415dd..33fd329 100644
--- a/arch/powerpc/mm/subpage-prot.c
+++ b/arch/powerpc/mm/subpage-prot.c
@@ -130,6 +130,14 @@ static void subpage_prot_clear(unsigned long addr, 
unsigned long len)
up_write(mm-mmap_sem);
 }
 
+static int subpage_walk_pmd_entry(pmd_t *pmd, unsigned long addr,
+ unsigned long end, struct mm_walk *walk)
+{
+   struct vm_area_struct *vma = walk-private;
+   split_huge_page_pmd(vma, addr, pmd);
+   return 0;
+}
+
 /*
  * Copy in a subpage protection map for an address range.
  * The map has 2 bits per 4k subpage, so 32 bits per 64k page.
@@ -149,6 +157,12 @@ long sys_subpage_prot(unsigned long addr, unsigned long 
len, u32 __user *map)
size_t nw;
unsigned long next, limit;
int err;
+   struct vm_area_struct *vma;
+
+   struct mm_walk subpage_proto_walk = {
+   .mm = mm,
+   .pmd_entry = subpage_walk_pmd_entry,
+   };
 
/* Check parameters */
if ((addr  ~PAGE_MASK) || (len  ~PAGE_MASK) ||
@@ -168,6 +182,19 @@ long sys_subpage_prot(unsigned long addr, unsigned long 
len, u32 __user *map)
return -EFAULT;
 
down_write(mm-mmap_sem);
+
+   /*
+* We don't try too hard, we just mark all the vma in that range
+* VM_NOHUGEPAGE and split them.
+*/
+   for (vma = find_vma(mm, addr);
+(vma  vma-vm_end  (addr + len)); vma = vma-vm_next) {
+
+   vma-vm_flags |= VM_NOHUGEPAGE;
+   subpage_proto_walk.private = vma;
+   walk_page_range(vma-vm_start, vma-vm_end,
+   subpage_proto_walk);
+   }
for (limit = addr + len; addr  limit; addr = next) {
next = pmd_addr_end(addr, limit);
err = -ENOMEM;
-- 
1.8.1.2

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

[PATCH 1/2] powerpc: use smp_rmb when looking at deposisted pgtable to store hash index

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

We need to use smb_rmb when looking at hpte slot array. Otherwise we could
reorder the hpte_slot array load bfore even we marked the pmd trans huge.

Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
 arch/powerpc/include/asm/pgtable-ppc64.h | 15 +++
 arch/powerpc/mm/hugepage-hash64.c|  6 +-
 arch/powerpc/mm/pgtable_64.c |  6 +-
 3 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h 
b/arch/powerpc/include/asm/pgtable-ppc64.h
index d046289..46db094 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -10,6 +10,7 @@
 #else
 #include asm/pgtable-ppc64-4k.h
 #endif
+#include asm/barrier.h
 
 #define FIRST_USER_ADDRESS 0
 
@@ -393,6 +394,20 @@ static inline void mark_hpte_slot_valid(unsigned char 
*hpte_slot_array,
hpte_slot_array[index] = hidx  4 | 0x1  3;
 }
 
+static inline char *get_hpte_slot_array(pmd_t *pmdp)
+{
+   /*
+* The hpte hindex is stored in the pgtable whose address is in the
+* second half of the PMD
+*
+* Order this load with the test for pmd_trans_huge in the caller
+*/
+   smp_rmb();
+   return *(char **)(pmdp + PTRS_PER_PMD);
+
+
+}
+
 extern void hpte_do_hugepage_flush(struct mm_struct *mm, unsigned long addr,
   pmd_t *pmdp);
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
diff --git a/arch/powerpc/mm/hugepage-hash64.c 
b/arch/powerpc/mm/hugepage-hash64.c
index e430766..c3ba3d5 100644
--- a/arch/powerpc/mm/hugepage-hash64.c
+++ b/arch/powerpc/mm/hugepage-hash64.c
@@ -84,11 +84,7 @@ int __hash_page_thp(unsigned long ea, unsigned long access, 
unsigned long vsid,
 
vpn = hpt_vpn(ea, vsid, ssize);
hash = hpt_hash(vpn, shift, ssize);
-   /*
-* The hpte hindex are stored in the pgtable whose address is in the
-* second half of the PMD
-*/
-   hpte_slot_array = *(char **)(pmdp + PTRS_PER_PMD);
+   hpte_slot_array = get_hpte_slot_array(pmdp);
 
valid = hpte_valid(hpte_slot_array, index);
if (valid) {
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index 8dd7c83..19d6734 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -701,11 +701,7 @@ void hpte_do_hugepage_flush(struct mm_struct *mm, unsigned 
long addr,
 * Flush all the hptes mapping this hugepage
 */
s_addr = addr  HPAGE_PMD_MASK;
-   /*
-* The hpte hindex are stored in the pgtable whose address is in the
-* second half of the PMD
-*/
-   hpte_slot_array = *(char **)(pmdp + PTRS_PER_PMD);
+   hpte_slot_array = get_hpte_slot_array(pmdp);
/*
 * IF we try to do a HUGE PTE update after a withdraw is done.
 * we will find the below NULL. This happens when we do
-- 
1.8.1.2

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

Re: [PATCH 2/2] powerpc: split hugepage when using subpage protection

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

 From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com

 We find all the overlapping vma and mark them such that we don't allocate
 hugepage in that range. Also we split existing huge page so that the
 normal page hash can be invalidated and new page faulted in with new
 protection bits.

 Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
 ---
  arch/powerpc/mm/subpage-prot.c | 27 +++
  1 file changed, 27 insertions(+)

 diff --git a/arch/powerpc/mm/subpage-prot.c b/arch/powerpc/mm/subpage-prot.c
 index 7c415dd..33fd329 100644
 --- a/arch/powerpc/mm/subpage-prot.c
 +++ b/arch/powerpc/mm/subpage-prot.c
 @@ -130,6 +130,14 @@ static void subpage_prot_clear(unsigned long addr, 
 unsigned long len)
   up_write(mm-mmap_sem);
  }

 +static int subpage_walk_pmd_entry(pmd_t *pmd, unsigned long addr,
 +   unsigned long end, struct mm_walk *walk)
 +{
 + struct vm_area_struct *vma = walk-private;
 + split_huge_page_pmd(vma, addr, pmd);
 + return 0;
 +}
 +
  /*
   * Copy in a subpage protection map for an address range.
   * The map has 2 bits per 4k subpage, so 32 bits per 64k page.
 @@ -149,6 +157,12 @@ long sys_subpage_prot(unsigned long addr, unsigned long 
 len, u32 __user *map)
   size_t nw;
   unsigned long next, limit;
   int err;
 + struct vm_area_struct *vma;
 +
 + struct mm_walk subpage_proto_walk = {
 + .mm = mm,
 + .pmd_entry = subpage_walk_pmd_entry,
 + };

   /* Check parameters */
   if ((addr  ~PAGE_MASK) || (len  ~PAGE_MASK) ||
 @@ -168,6 +182,19 @@ long sys_subpage_prot(unsigned long addr, unsigned long 
 len, u32 __user *map)
   return -EFAULT;

   down_write(mm-mmap_sem);
 +
 + /*
 +  * We don't try too hard, we just mark all the vma in that range
 +  * VM_NOHUGEPAGE and split them.
 +  */
 + for (vma = find_vma(mm, addr);
 +  (vma  vma-vm_end  (addr + len)); vma = vma-vm_next) {

should be, Missed commit -amend 

 (vma  vma-vm_start  (addr + len)); vma = vma-vm_next) {

 + vma-vm_flags |= VM_NOHUGEPAGE;
 + subpage_proto_walk.private = vma;
 + walk_page_range(vma-vm_start, vma-vm_end,
 + subpage_proto_walk);
 + }
   for (limit = addr + len; addr  limit; addr = next) {
   next = pmd_addr_end(addr, limit);
   err = -ENOMEM;

-aneesh

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

Re: [PATCH] can: flexcan: allow compilation on arm and powerpc

2013-05-17 Thread Marc Kleine-Budde 
On 05/17/2013 04:03 AM, Shawn Guo wrote:
 Hi Marc,
 
 On Thu, May 16, 2013 at 03:42:36PM +0200, Marc Kleine-Budde wrote:
 This patch removes the Kconfig symbols HAVE_CAN_FLEXCAN and
 IMX_HAVE_PLATFORM_FLEXCAN from arch/{arm,powerpc} and allowing compilation on
 all arm and powerpc platforms.
 
 I'm generally fine with the approach.  But with Kconfig symbol
 IMX_HAVE_PLATFORM_FLEXCAN removed, how does the build of
 platform-flexcan.o work?
 
 arch/arm/mach-imx/devices/Makefile:obj-$(CONFIG_IMX_HAVE_PLATFORM_FLEXCAN) += 
 platform-flexcan.o

Doh! - I've removed too much, will change.

Tnx,
Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



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

[PATCH v2] can: flexcan: remove HAVE_CAN_FLEXCAN Kconfig symbol

2013-05-17 Thread Marc Kleine-Budde 
This patch removes the Kconfig symbol HAVE_CAN_FLEXCAN from arch/{arm,powerpc}
and allowing compilation unconditionally on all arm and powerpc platforms.

This brings a bigger compile time coverage and removes the following dependency
warning found by Arnd Bergmann:

warning: (SOC_IMX28  SOC_IMX25  SOC_IMX35  IMX_HAVE_PLATFORM_FLEXCAN 

SOC_IMX53  SOC_IMX6Q) selects HAVE_CAN_FLEXCAN
which has unmet direct dependencies (NET  CAN  CAN_DEV)

Cc: Arnd Bergmann a...@arndb.de
Cc: Shawn Guo shawn@linaro.org
Cc: Sascha Hauer s.ha...@pengutronix.de
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: U Bhaskar-B22300 b22...@freescale.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
---
Changes since v1:
- don't remove IMX_HAVE_PLATFORM_FLEXCAN, which breaks non DT imx platforms
  tnx Shawn

 arch/arm/mach-imx/Kconfig | 4 
 arch/arm/mach-imx/devices/Kconfig | 1 -
 arch/arm/mach-mxs/Kconfig | 1 -
 arch/powerpc/Kconfig  | 1 -
 drivers/net/can/Kconfig   | 5 +
 5 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index ba44328..af8e109 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -111,7 +111,6 @@ config SOC_IMX25
select ARCH_MXC_IOMUX_V3
select COMMON_CLK
select CPU_ARM926T
-   select HAVE_CAN_FLEXCAN if CAN
select MXC_AVIC
 
 config SOC_IMX27
@@ -137,7 +136,6 @@ config SOC_IMX35
select ARCH_MXC_IOMUX_V3
select COMMON_CLK
select CPU_V6K
-   select HAVE_CAN_FLEXCAN if CAN
select HAVE_EPIT
select MXC_AVIC
select SMP_ON_UP if SMP
@@ -776,7 +774,6 @@ comment Device tree only
 
 config SOC_IMX53
bool i.MX53 support
-   select HAVE_CAN_FLEXCAN if CAN
select HAVE_IMX_SRC
select IMX_HAVE_PLATFORM_IMX2_WDT
select PINCTRL
@@ -799,7 +796,6 @@ config SOC_IMX6Q
select CPU_V7
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if LOCAL_TIMERS
-   select HAVE_CAN_FLEXCAN if CAN
select HAVE_IMX_ANATOP
select HAVE_IMX_GPC
select HAVE_IMX_MMDC
diff --git a/arch/arm/mach-imx/devices/Kconfig 
b/arch/arm/mach-imx/devices/Kconfig
index 3dd2b1b..68c74fb 100644
--- a/arch/arm/mach-imx/devices/Kconfig
+++ b/arch/arm/mach-imx/devices/Kconfig
@@ -4,7 +4,6 @@ config IMX_HAVE_PLATFORM_FEC
 
 config IMX_HAVE_PLATFORM_FLEXCAN
bool
-   select HAVE_CAN_FLEXCAN if CAN
 
 config IMX_HAVE_PLATFORM_FSL_USB2_UDC
bool
diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
index 4dc2fbb..ce6e7d6 100644
--- a/arch/arm/mach-mxs/Kconfig
+++ b/arch/arm/mach-mxs/Kconfig
@@ -11,7 +11,6 @@ config SOC_IMX28
select ARM_AMBA
select ARM_CPU_SUSPEND if PM
select CPU_ARM926T
-   select HAVE_CAN_FLEXCAN if CAN
select HAVE_PWM
select PINCTRL_IMX28
 
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..7754c6b 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -674,7 +674,6 @@ config SBUS
 
 config FSL_SOC
bool
-   select HAVE_CAN_FLEXCAN if NET  CAN
 
 config FSL_PCI
bool
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index e456b70..3c06947 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -102,12 +102,9 @@ config CAN_JANZ_ICAN3
  This driver can also be built as a module. If so, the module will be
  called janz-ican3.ko.
 
-config HAVE_CAN_FLEXCAN
-   bool
-
 config CAN_FLEXCAN
tristate Support for Freescale FLEXCAN based chips
-   depends on HAVE_CAN_FLEXCAN
+   depends on ARM || PPC
---help---
  Say Y here if you want to support for Freescale FlexCAN.
 
-- 
1.8.2.rc2

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

Re: [PATCH v2] can: flexcan: remove HAVE_CAN_FLEXCAN Kconfig symbol

2013-05-17 Thread Shawn Guo 
On Fri, May 17, 2013 at 10:59:17AM +0200, Marc Kleine-Budde wrote:
 This patch removes the Kconfig symbol HAVE_CAN_FLEXCAN from arch/{arm,powerpc}
 and allowing compilation unconditionally on all arm and powerpc platforms.
 
 This brings a bigger compile time coverage and removes the following 
 dependency
 warning found by Arnd Bergmann:
 
 warning: (SOC_IMX28  SOC_IMX25  SOC_IMX35  
 IMX_HAVE_PLATFORM_FLEXCAN 
 SOC_IMX53  SOC_IMX6Q) selects HAVE_CAN_FLEXCAN
 which has unmet direct dependencies (NET  CAN  CAN_DEV)
 
 Cc: Arnd Bergmann a...@arndb.de
 Cc: Shawn Guo shawn@linaro.org

Acked-by: Shawn Guo shawn@linaro.org

 Cc: Sascha Hauer s.ha...@pengutronix.de
 Cc: Kumar Gala ga...@kernel.crashing.org
 Cc: U Bhaskar-B22300 b22...@freescale.com
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linuxppc-dev@lists.ozlabs.org
 Signed-off-by: Marc Kleine-Budde m...@pengutronix.de

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

Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL

2013-05-17 Thread Peter Zijlstra 
On Thu, May 16, 2013 at 05:36:11PM +0200, Stephane Eranian wrote:
 On Thu, May 16, 2013 at 1:16 PM, Peter Zijlstra pet...@infradead.org wrote:
  On Thu, May 16, 2013 at 08:15:17PM +1000, Michael Neuling wrote:
  Peter,
 
  BTW PowerPC also has the ability to filter on conditional branches.  Any
  chance we could add something like the follow to perf also?
 
 
  I don't see an immediate problem with that except that we on x86 need to
  implement that in the software filter. Stephane do you see any
  fundamental issue with that?
 
 On X86, the LBR cannot filter on conditional in HW. Thus as Peter said, it 
 would
 have to be done in SW. I did not add that because I think those branches are
 not necessarily useful for tools.

Wouldn't it be mostly conditional branches that are the primary control flow
and can get predicted wrong? I mean, I'm sure someone will miss-predict an
unconditional branch but its not like we care about people with such
afflictions do we?

Anyway, since PPC people thought it worth baking into hardware, presumably they
have a compelling use case. Mikey could you see if you can retrieve that from
someone in the know? It might be interesting.

Also, it looks like its trivial to add to x86, you seem to have already done
all the hard work by having X86_BR_JCC.

The only missing piece would be:

--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -337,6 +337,10 @@ static int intel_pmu_setup_sw_lbr_filter
 
if (br_type  PERF_SAMPLE_BRANCH_IND_CALL)
mask |= X86_BR_IND_CALL;
+
+   if (br_type  PERF_SAMPLE_BRANCH_CONDITIONAL)
+   mask |= X86_BR_JCC;
+
/*
 * stash actual user request into reg, it may
 * be used by fixup code for some CPU
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL

2013-05-17 Thread Michael Neuling 
Peter Zijlstra pet...@infradead.org wrote:

 On Thu, May 16, 2013 at 05:36:11PM +0200, Stephane Eranian wrote:
  On Thu, May 16, 2013 at 1:16 PM, Peter Zijlstra pet...@infradead.org 
  wrote:
   On Thu, May 16, 2013 at 08:15:17PM +1000, Michael Neuling wrote:
   Peter,
  
   BTW PowerPC also has the ability to filter on conditional branches.  Any
   chance we could add something like the follow to perf also?
  
  
   I don't see an immediate problem with that except that we on x86 need to
   implement that in the software filter. Stephane do you see any
   fundamental issue with that?
  
  On X86, the LBR cannot filter on conditional in HW. Thus as Peter said, it 
  would
  have to be done in SW. I did not add that because I think those branches are
  not necessarily useful for tools.
 
 Wouldn't it be mostly conditional branches that are the primary control flow
 and can get predicted wrong? I mean, I'm sure someone will miss-predict an
 unconditional branch but its not like we care about people with such
 afflictions do we?

You could mispredict the target address of a computed goto.  You'd know
it was taken but not know target address until later in the pipeline.

On this, the POWER8 branch history buffer tells us two things about the
prediction status.  
  1) if the branch was predicted taken/not taken correctly
  2) if the target address was predicted correctly or not (for computed
 gotos only)
So we'd actually like more prediction bits too :-D

 Anyway, since PPC people thought it worth baking into hardware,
 presumably they have a compelling use case. Mikey could you see if you
 can retrieve that from someone in the know? It might be interesting.

I don't think we can mispredict a non-conditional non-computed but I'll
have to check with the HW folks.

Mikey


 Also, it looks like its trivial to add to x86, you seem to have already done
 all the hard work by having X86_BR_JCC.
 
 The only missing piece would be:
 
 --- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
 +++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
 @@ -337,6 +337,10 @@ static int intel_pmu_setup_sw_lbr_filter
  
   if (br_type  PERF_SAMPLE_BRANCH_IND_CALL)
   mask |= X86_BR_IND_CALL;
 +
 + if (br_type  PERF_SAMPLE_BRANCH_CONDITIONAL)
 + mask |= X86_BR_JCC;
 +
   /*
* stash actual user request into reg, it may
* be used by fixup code for some CPU
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL

2013-05-17 Thread Peter Zijlstra 
On Fri, May 17, 2013 at 09:32:08PM +1000, Michael Neuling wrote:
 Peter Zijlstra pet...@infradead.org wrote:

  Wouldn't it be mostly conditional branches that are the primary control flow
  and can get predicted wrong? I mean, I'm sure someone will miss-predict an
  unconditional branch but its not like we care about people with such
  afflictions do we?
 
 You could mispredict the target address of a computed goto.  You'd know
 it was taken but not know target address until later in the pipeline.

Oh right, computed targets could indeed be mis predicted. I was more thinking
about jumps with immediate values.

 On this, the POWER8 branch history buffer tells us two things about the
 prediction status.  
   1) if the branch was predicted taken/not taken correctly
   2) if the target address was predicted correctly or not (for computed
  gotos only)
 So we'd actually like more prediction bits too :-D

So if I understand this right, 1) maps to the predicted flags we have; 2)
would be new stuff?

We don't really have anything like that on x86, but I suppose if you make the
thing optional and present a 'useful' use-case implemented in userspace code
we could take it :-)

  Anyway, since PPC people thought it worth baking into hardware,
  presumably they have a compelling use case. Mikey could you see if you
  can retrieve that from someone in the know? It might be interesting.
 
 I don't think we can mispredict a non-conditional non-computed but I'll
 have to check with the HW folks.

I was mostly wondering about the use-case for the conditional filter. Stephane
didn't think it useful, clearly your hardware guys thought different :-)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs

2013-05-17 Thread Dennis Schridde 
Hello!

Am Dienstag, 23. April 2013, 19:12:47 schrieb Michael Ellerman:
 For me it is fixed by applying the following patch, it should be in v3.10:
 
   http://patchwork.ozlabs.org/patch/230103/

Can you please also backport this to 3.8? It is still missing in 3.8.12.

The patch for cbe_init_pm_irq() was included - Thanks!

--Dennis

signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/cell: Only iterate over online nodes in cbe_init_pm_irq()

2013-05-17 Thread Dennis Schridde 
Hello!

Just wanted to remind you: The patchto fix cbe_init_pm_irq() that Michael and 
Grant sent me is still not included in Linux 3.8.12.

--Dennis

Am Dienstag, 23. April 2013, 22:14:51 schrieb Michael Ellerman:
 None of the cell platforms support CPU hotplug, so we should iterate
 only over online nodes when setting PMU interrupts.
 
 This also fixes a warning during boot when NODES_SHIFT is large enough:
 
 WARNING: at /scratch/michael/src/kmk/linus/kernel/irq/irqdomain.c:766
 ...
 NIP [c00db278] .irq_linear_revmap+0x30/0x58
 LR [c00dc2a0] .irq_create_mapping+0x38/0x1a8
 Call Trace:
 [c003fc9c3af0] [c00dc2a0] .irq_create_mapping+0x38/0x1a8
 (unreliable) [c003fc9c3b80] [c0655c1c]
 .__machine_initcall_cell_cbe_init_pm_irq+0x84/0x158 [c003fc9c3c20]
 [c000afb4] .do_one_initcall+0x5c/0x1e0
 [c003fc9c3cd0] [c0644580] .kernel_init_freeable+0x238/0x328
 [c003fc9c3db0] [c000b784] .kernel_init+0x1c/0x120
 [c003fc9c3e30] [c0009fb8] .ret_from_kernel_thread+0x64/0xac
 
 This is caused by us overflowing our linear revmap because we're
 requesting too many interrupts.
 
 Reported-by: Dennis Schridde devuran...@gmx.net
 Signed-off-by: Michael Ellerman mich...@ellerman.id.au
 ---
  arch/powerpc/platforms/cell/pmu.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/powerpc/platforms/cell/pmu.c
 b/arch/powerpc/platforms/cell/pmu.c index 59c1a16..348a27b 100644
 --- a/arch/powerpc/platforms/cell/pmu.c
 +++ b/arch/powerpc/platforms/cell/pmu.c
 @@ -382,7 +382,7 @@ static int __init cbe_init_pm_irq(void)
   unsigned int irq;
   int rc, node;
 
 - for_each_node(node) {
 + for_each_online_node(node) {
   irq = irq_create_mapping(NULL, IIC_IRQ_IOEX_PMI |
  (node  IIC_IRQ_NODE_SHIFT));
   if (irq == NO_IRQ) {

signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 20/21] powerpc/ps3: remove inline marking of EXPORT_SYMBOL functions

2013-05-17 Thread Geert Uytterhoeven 
On Thu, May 9, 2013 at 12:36 PM, Denis Efremov yefremov.de...@gmail.com wrote:
 EXPORT_SYMBOL and inline directives are contradictory to each other.
 The patch fixes this inconsistency.

 Found by Linux Driver Verification project (linuxtesting.org).

 Signed-off-by: Denis Efremov yefremov.de...@gmail.com
 ---
  arch/powerpc/platforms/ps3/spu.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/arch/powerpc/platforms/ps3/spu.c 
 b/arch/powerpc/platforms/ps3/spu.c
 index e17fa14..a0bca05 100644
 --- a/arch/powerpc/platforms/ps3/spu.c
 +++ b/arch/powerpc/platforms/ps3/spu.c
 @@ -143,7 +143,7 @@ static void _dump_areas(unsigned int spe_id, unsigned 
 long priv2,
 pr_debug(%s:%d: shadow:  %lxh\n, func, line, shadow);
  }

 -inline u64 ps3_get_spe_id(void *arg)
 +u64 ps3_get_spe_id(void *arg)
  {
 return spu_pdata(arg)-spe_id;
  }

FYI, this symbol is not used in mainline.

IIRC, it's used for profiling only. Any chance the profile code will
ever make it
in mainline?

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL

2013-05-17 Thread Stephane Eranian 
On Fri, May 17, 2013 at 1:39 PM, Peter Zijlstra pet...@infradead.org wrote:
 On Fri, May 17, 2013 at 09:32:08PM +1000, Michael Neuling wrote:
 Peter Zijlstra pet...@infradead.org wrote:

  Wouldn't it be mostly conditional branches that are the primary control 
  flow
  and can get predicted wrong? I mean, I'm sure someone will miss-predict an
  unconditional branch but its not like we care about people with such
  afflictions do we?

 You could mispredict the target address of a computed goto.  You'd know
 it was taken but not know target address until later in the pipeline.

 Oh right, computed targets could indeed be mis predicted. I was more thinking
 about jumps with immediate values.

 On this, the POWER8 branch history buffer tells us two things about the
 prediction status.
   1) if the branch was predicted taken/not taken correctly
   2) if the target address was predicted correctly or not (for computed
  gotos only)
 So we'd actually like more prediction bits too :-D

 So if I understand this right, 1) maps to the predicted flags we have; 2)
 would be new stuff?

 We don't really have anything like that on x86, but I suppose if you make the
 thing optional and present a 'useful' use-case implemented in userspace code
 we could take it :-)

  Anyway, since PPC people thought it worth baking into hardware,
  presumably they have a compelling use case. Mikey could you see if you
  can retrieve that from someone in the know? It might be interesting.

 I don't think we can mispredict a non-conditional non-computed but I'll
 have to check with the HW folks.

 I was mostly wondering about the use-case for the conditional filter. Stephane
 didn't think it useful, clearly your hardware guys thought different :-)

From my experience talking with compiler people, they care about ALL
the branches
and not the conditional so much. They use LBR to do basic block profiling.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL

2013-05-17 Thread Michael Neuling 
Stephane Eranian eran...@google.com wrote:

 On Fri, May 17, 2013 at 1:39 PM, Peter Zijlstra pet...@infradead.org wrote:
  On Fri, May 17, 2013 at 09:32:08PM +1000, Michael Neuling wrote:
  Peter Zijlstra pet...@infradead.org wrote:
 
   Wouldn't it be mostly conditional branches that are the primary control 
   flow
   and can get predicted wrong? I mean, I'm sure someone will miss-predict 
   an
   unconditional branch but its not like we care about people with such
   afflictions do we?
 
  You could mispredict the target address of a computed goto.  You'd know
  it was taken but not know target address until later in the pipeline.
 
  Oh right, computed targets could indeed be mis predicted. I was more 
  thinking
  about jumps with immediate values.
 
  On this, the POWER8 branch history buffer tells us two things about the
  prediction status.
1) if the branch was predicted taken/not taken correctly
2) if the target address was predicted correctly or not (for computed
   gotos only)
  So we'd actually like more prediction bits too :-D
 
  So if I understand this right, 1) maps to the predicted flags we have; 2)
  would be new stuff?
 
  We don't really have anything like that on x86, but I suppose if you make 
  the
  thing optional and present a 'useful' use-case implemented in userspace code
  we could take it :-)
 
   Anyway, since PPC people thought it worth baking into hardware,
   presumably they have a compelling use case. Mikey could you see if you
   can retrieve that from someone in the know? It might be interesting.
 
  I don't think we can mispredict a non-conditional non-computed but I'll
  have to check with the HW folks.
 
  I was mostly wondering about the use-case for the conditional filter. 
  Stephane
  didn't think it useful, clearly your hardware guys thought different :-)
 
 From my experience talking with compiler people, they care about ALL
 the branches and not the conditional so much. They use LBR to do basic
 block profiling.

OK.  I don't have a good handle on what's useful for compilers or JITs
right now.  I'm just plumbing through what's possible.

Mikey

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

Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL

2013-05-17 Thread Stephane Eranian 
On Sat, May 18, 2013 at 12:14 AM, Michael Neuling mi...@neuling.org wrote:
 Stephane Eranian eran...@google.com wrote:

 On Fri, May 17, 2013 at 1:39 PM, Peter Zijlstra pet...@infradead.org wrote:
  On Fri, May 17, 2013 at 09:32:08PM +1000, Michael Neuling wrote:
  Peter Zijlstra pet...@infradead.org wrote:
 
   Wouldn't it be mostly conditional branches that are the primary control 
   flow
   and can get predicted wrong? I mean, I'm sure someone will miss-predict 
   an
   unconditional branch but its not like we care about people with such
   afflictions do we?
 
  You could mispredict the target address of a computed goto.  You'd know
  it was taken but not know target address until later in the pipeline.
 
  Oh right, computed targets could indeed be mis predicted. I was more 
  thinking
  about jumps with immediate values.
 
  On this, the POWER8 branch history buffer tells us two things about the
  prediction status.
1) if the branch was predicted taken/not taken correctly
2) if the target address was predicted correctly or not (for computed
   gotos only)
  So we'd actually like more prediction bits too :-D
 
  So if I understand this right, 1) maps to the predicted flags we have; 2)
  would be new stuff?
 
  We don't really have anything like that on x86, but I suppose if you make 
  the
  thing optional and present a 'useful' use-case implemented in userspace 
  code
  we could take it :-)
 
   Anyway, since PPC people thought it worth baking into hardware,
   presumably they have a compelling use case. Mikey could you see if you
   can retrieve that from someone in the know? It might be interesting.
 
  I don't think we can mispredict a non-conditional non-computed but I'll
  have to check with the HW folks.
 
  I was mostly wondering about the use-case for the conditional filter. 
  Stephane
  didn't think it useful, clearly your hardware guys thought different :-)

 From my experience talking with compiler people, they care about ALL
 the branches and not the conditional so much. They use LBR to do basic
 block profiling.

 OK.  I don't have a good handle on what's useful for compilers or JITs
 right now.  I'm just plumbing through what's possible.

I understand. It is okay to extend the interface.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev