Re: Build regressions/improvements in v3.12-rc5
On Tue, Oct 15, 2013 at 8:34 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
JFYI, when comparing v3.12-rc5 to v3.12-rc4[3], the summaries are:
- build errors: +13/-6
+ /scratch/kisskb/src/arch/powerpc/kernel/fadump.c: error:
'KEXEC_CORE_NOTE_NAME' undeclared (first use in this function): =
521:36
+ /scratch/kisskb/src/arch/powerpc/kernel/fadump.c: error:
'crashing_cpu' undeclared (first use in this function): = 408:2
+ /scratch/kisskb/src/arch/powerpc/kernel/fadump.c: error:
'note_buf_t' undeclared (first use in this function): = 624:49
+ /scratch/kisskb/src/arch/powerpc/kernel/fadump.c: error:
'vmcoreinfo_max_size' undeclared (first use in this function): =
874:18
+ /scratch/kisskb/src/arch/powerpc/kernel/fadump.c: error: implicit
declaration of function 'crash_save_vmcoreinfo'
[-Werror=implicit-function-declaration]: = 410:2
+ /scratch/kisskb/src/arch/powerpc/kernel/fadump.c: error: implicit
declaration of function 'elf_core_copy_kernel_regs'
[-Werror=implicit-function-declaration]: = 520:2
+ /scratch/kisskb/src/arch/powerpc/kernel/fadump.c: error: implicit
declaration of function 'paddr_vmcoreinfo_note'
[-Werror=implicit-function-declaration]: = 872:2
+ /scratch/kisskb/src/arch/powerpc/kernel/fadump.c: error: storage
size of 'prstatus' isn't known: = 513:22
powerpc-randconfig
+ /scratch/kisskb/src/arch/sh/drivers/dma/dma-sh.c: error:
'DMTE6_IRQ' undeclared (first use in this function): = 58:21
+ /scratch/kisskb/src/drivers/gpu/drm/drm_gem_cma_helper.c: error:
implicit declaration of function 'dma_alloc_writecombine'
[-Werror=implicit-function-declaration]: = 91:2
+ /scratch/kisskb/src/drivers/gpu/drm/drm_gem_cma_helper.c: error:
implicit declaration of function 'dma_free_writecombine'
[-Werror=implicit-function-declaration]: = 176:3
sh-randconfig
[1] http://kisskb.ellerman.id.au/kisskb/head/6776/ (all 120 configs)
[3] http://kisskb.ellerman.id.au/kisskb/head/6753/ (all 120 configs)
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 -V2 00/14] Allow PR and HV KVM to coexist in one kernel
Hi Alex, Any update on this ? -aneesh Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com writes: Hi All, This patch series support enabling HV and PR KVM together in the same kernel. We extend machine property with new property kvm_type. A value of HV will force HV KVM and PR PR KVM. If we don't specify kvm_type we will select the fastest KVM mode. ie, HV if that is supported otherwise PR. With Qemu command line having -machine pseries,accel=kvm,kvm_type=HV [root@llmp24l02 qemu]# bash ../qemu failed to initialize KVM: Invalid argument [root@llmp24l02 qemu]# modprobe kvm-pr [root@llmp24l02 qemu]# bash ../qemu failed to initialize KVM: Invalid argument [root@llmp24l02 qemu]# modprobe kvm-hv [root@llmp24l02 qemu]# bash ../qemu now with -machine pseries,accel=kvm,kvm_type=PR [root@llmp24l02 qemu]# rmmod kvm-pr [root@llmp24l02 qemu]# bash ../qemu failed to initialize KVM: Invalid argument [root@llmp24l02 qemu]# [root@llmp24l02 qemu]# modprobe kvm-pr [root@llmp24l02 qemu]# bash ../qemu Changes from V1: * Build fixes for BOOKE (only compile tested) * Address review feedback -aneesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define
From: Wang Dongsheng dongsheng.w...@freescale.com E6500 PVR and SPRN_PWRMGTCR0 will be used in subsequent pw20/altivec idle patches. Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com --- *v3: Add bit definitions for PWRMGTCR0. arch/powerpc/include/asm/reg.h | 2 ++ arch/powerpc/include/asm/reg_booke.h | 9 + 2 files changed, 11 insertions(+) diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index 64264bf..d4160ca 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -1053,6 +1053,8 @@ #define PVR_8560 0x8020 #define PVR_VER_E500V1 0x8020 #define PVR_VER_E500V2 0x8021 +#define PVR_VER_E6500 0x8040 + /* * For the 8xx processors, all of them report the same PVR family for * the PowerPC core. The various versions of these processors must be diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h index ed8f836..4a6457e 100644 --- a/arch/powerpc/include/asm/reg_booke.h +++ b/arch/powerpc/include/asm/reg_booke.h @@ -170,6 +170,7 @@ #define SPRN_L2CSR10x3FA /* L2 Data Cache Control and Status Register 1 */ #define SPRN_DCCR 0x3FA /* Data Cache Cacheability Register */ #define SPRN_ICCR 0x3FB /* Instruction Cache Cacheability Register */ +#define SPRN_PWRMGTCR0 0x3FB /* Power management control register 0 */ #define SPRN_SVR 0x3FF /* System Version Register */ /* @@ -216,6 +217,14 @@ #defineCCR1_DPC0x0100 /* Disable L1 I-Cache/D-Cache parity checking */ #defineCCR1_TCS0x0080 /* Timer Clock Select */ +/* Bit definitions for PWRMGTCR0. */ +#define PWRMGTCR0_PW20_WAIT(1 14) /* PW20 state enable bit */ +#define PWRMGTCR0_PW20_ENT_SHIFT 8 +#define PWRMGTCR0_PW20_ENT 0x3F00 +#define PWRMGTCR0_AV_IDLE_PD_EN(1 22) /* Altivec idle enable */ +#define PWRMGTCR0_AV_IDLE_CNT_SHIFT16 +#define PWRMGTCR0_AV_IDLE_CNT 0x3F + /* Bit definitions for the MCSR. */ #define MCSR_MCS 0x8000 /* Machine Check Summary */ #define MCSR_IB0x4000 /* Instruction PLB Error */ -- 1.8.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 2/4] powerpc/85xx: add hardware automatically enter altivec idle state
From: Wang Dongsheng dongsheng.w...@freescale.com Each core's AltiVec unit may be placed into a power savings mode by turning off power to the unit. Core hardware will automatically power down the AltiVec unit after no AltiVec instructions have executed in N cycles. The AltiVec power-control is triggered by hardware. Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com --- *v3: Assembly code instead of C code. *v2: Remove: delete setup_idle_hw_governor function. delete Fix erratum for rev1. Move: move setup_* into __setup/restore_cpu_e6500. arch/powerpc/kernel/cpu_setup_fsl_booke.S | 21 + 1 file changed, 21 insertions(+) diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S index bfb18c7..4789056 100644 --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S @@ -53,11 +53,31 @@ _GLOBAL(__e500_dcache_setup) isync blr +/* + * FIXME - we haven't yet done testing to determine a reasonable default + * value for AV_WAIT_IDLE_BIT. + */ +#define AV_WAIT_IDLE_BIT 50 /* 1ms, TB frequency is 41.66MHZ */ +_GLOBAL(setup_altivec_idle) + mfspr r3, SPRN_PWRMGTCR0 + + /* Enable Altivec Idle */ + orisr3, r3, PWRMGTCR0_AV_IDLE_PD_EN@h + li r11, AV_WAIT_IDLE_BIT + + /* Set Automatic AltiVec Idle Count */ + rlwimi r3, r11, PWRMGTCR0_AV_IDLE_CNT_SHIFT, PWRMGTCR0_AV_IDLE_CNT + + mtspr SPRN_PWRMGTCR0, r3 + + blr + _GLOBAL(__setup_cpu_e6500) mflrr6 #ifdef CONFIG_PPC64 bl .setup_altivec_ivors #endif + bl setup_altivec_idle bl __setup_cpu_e5500 mtlrr6 blr @@ -119,6 +139,7 @@ _GLOBAL(__setup_cpu_e5500) _GLOBAL(__restore_cpu_e6500) mflrr5 bl .setup_altivec_ivors + bl .setup_altivec_idle bl __restore_cpu_e5500 mtlrr5 blr -- 1.8.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 3/4] powerpc/85xx: add hardware automatically enter pw20 state
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 --- *v3: Assembly code instead of C code. *v2: Remove: delete setup_idle_hw_governor function. delete Fix erratum for rev1. Move: move setup_* into __setup/restore_cpu_e6500. arch/powerpc/kernel/cpu_setup_fsl_booke.S | 21 + 1 file changed, 21 insertions(+) diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S index 4789056..49e738e 100644 --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S @@ -55,6 +55,25 @@ _GLOBAL(__e500_dcache_setup) /* * FIXME - we haven't yet done testing to determine a reasonable default + * value for PW20_WAIT_IDLE_BIT. + */ +#define PW20_WAIT_IDLE_BIT 50 /* 1ms, TB frequency is 41.66MHZ */ +_GLOBAL(setup_pw20_idle) + mfspr r3, SPRN_PWRMGTCR0 + + /* Set PW20_WAIT bit, enable pw20 state*/ + ori r3, r3, PWRMGTCR0_PW20_WAIT + li r11, PW20_WAIT_IDLE_BIT + + /* Set Automatic PW20 Core Idle Count */ + rlwimi r3, r11, PWRMGTCR0_PW20_ENT_SHIFT, PWRMGTCR0_PW20_ENT + + mtspr SPRN_PWRMGTCR0, r3 + + blr + +/* + * FIXME - we haven't yet done testing to determine a reasonable default * value for AV_WAIT_IDLE_BIT. */ #define AV_WAIT_IDLE_BIT 50 /* 1ms, TB frequency is 41.66MHZ */ @@ -77,6 +96,7 @@ _GLOBAL(__setup_cpu_e6500) #ifdef CONFIG_PPC64 bl .setup_altivec_ivors #endif + bl setup_pw20_idle bl setup_altivec_idle bl __setup_cpu_e5500 mtlrr6 @@ -139,6 +159,7 @@ _GLOBAL(__setup_cpu_e5500) _GLOBAL(__restore_cpu_e6500) mflrr5 bl .setup_altivec_ivors + bl .setup_pw20_idle bl .setup_altivec_idle bl __restore_cpu_e5500 mtlrr5 -- 1.8.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Wang Dongsheng dongsheng.w...@freescale.com
Add a sys interface to enable/diable pw20 state or altivec idle, and
control the wait entry time.
Enable/Disable interface:
0, disable. 1, enable.
/sys/devices/system/cpu/cpuX/pw20_state
/sys/devices/system/cpu/cpuX/altivec_idle
Set wait time interface:(Nanosecond)
/sys/devices/system/cpu/cpuX/pw20_wait_time
/sys/devices/system/cpu/cpuX/altivec_idle_wait_time
Example: Base on TBfreq is 41MHZ.
1~48(ns): TB[63]
49~97(ns): TB[62]
98~195(ns): TB[61]
196~390(ns): TB[60]
391~780(ns): TB[59]
781~1560(ns): TB[58]
...
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
*v5:
Change get_idle_ticks_bit function implementation.
*v4:
Move code from 85xx/common.c to kernel/sysfs.c.
Remove has_pw20_altivec_idle function.
Change wait entry_bit to wait time.
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 27a90b9..10d1128 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -85,6 +85,284 @@ __setup(smt-snooze-delay=, setup_smt_snooze_delay);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+#define MAX_BIT63
+
+static u64 pw20_wt;
+static u64 altivec_idle_wt;
+
+static unsigned int get_idle_ticks_bit(u64 ns)
+{
+ u64 cycle;
+
+ if (ns = 1)
+ cycle = div_u64(ns + 500, 1000) * tb_ticks_per_usec;
+ else
+ cycle = div_u64(ns * tb_ticks_per_usec, 1000);
+
+ if (!cycle)
+ return 0;
+
+ return ilog2(cycle);
+}
+
+static void do_show_pwrmgtcr0(void *val)
+{
+ u32 *value = val;
+
+ *value = mfspr(SPRN_PWRMGTCR0);
+}
+
+static ssize_t show_pw20_state(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ u32 value;
+ unsigned int cpu = dev-id;
+
+ smp_call_function_single(cpu, do_show_pwrmgtcr0, value, 1);
+
+ value = PWRMGTCR0_PW20_WAIT;
+
+ return sprintf(buf, %u\n, value ? 1 : 0);
+}
+
+static void do_store_pw20_state(void *val)
+{
+ u32 *value = val;
+ u32 pw20_state;
+
+ pw20_state = mfspr(SPRN_PWRMGTCR0);
+
+ if (*value)
+ pw20_state |= PWRMGTCR0_PW20_WAIT;
+ else
+ pw20_state = ~PWRMGTCR0_PW20_WAIT;
+
+ mtspr(SPRN_PWRMGTCR0, pw20_state);
+}
+
+static ssize_t store_pw20_state(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ u32 value;
+ unsigned int cpu = dev-id;
+
+ if (kstrtou32(buf, 0, value))
+ return -EINVAL;
+
+ if (value 1)
+ return -EINVAL;
+
+ smp_call_function_single(cpu, do_store_pw20_state, value, 1);
+
+ return count;
+}
+
+static ssize_t show_pw20_wait_time(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ u32 value;
+ u64 tb_cycle;
+ s64 time;
+
+ unsigned int cpu = dev-id;
+
+ if (!pw20_wt) {
+ smp_call_function_single(cpu, do_show_pwrmgtcr0, value, 1);
+ value = (value PWRMGTCR0_PW20_ENT)
+ PWRMGTCR0_PW20_ENT_SHIFT;
+
+ tb_cycle = (1 (MAX_BIT - value)) * 2;
+ time = div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
+ } else {
+ time = pw20_wt;
+ }
+
+ return sprintf(buf, %llu\n, time 0 ? time : 0);
+}
+
+static void set_pw20_wait_entry_bit(void *val)
+{
+ u32 *value = val;
+ u32 pw20_idle;
+
+ pw20_idle = mfspr(SPRN_PWRMGTCR0);
+
+ /* Set Automatic PW20 Core Idle Count */
+ /* clear count */
+ pw20_idle = ~PWRMGTCR0_PW20_ENT;
+
+ /* set count */
+ pw20_idle |= ((MAX_BIT - *value) PWRMGTCR0_PW20_ENT_SHIFT);
+
+ mtspr(SPRN_PWRMGTCR0, pw20_idle);
+}
+
+static ssize_t store_pw20_wait_time(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ u32 entry_bit;
+ u64 value;
+
+ unsigned int cpu = dev-id;
+
+ if (kstrtou64(buf, 0, value))
+ return -EINVAL;
+
+ if (!value)
+ return -EINVAL;
+
+ entry_bit = get_idle_ticks_bit(value);
+ if (entry_bit MAX_BIT)
+ return -EINVAL;
+
+ pw20_wt = value;
+ smp_call_function_single(cpu, set_pw20_wait_entry_bit,
+ entry_bit, 1);
+
+ return count;
+}
+
+static ssize_t show_altivec_idle(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ u32 value;
+ unsigned int cpu = dev-id;
+
+ smp_call_function_single(cpu, do_show_pwrmgtcr0, value, 1);
+
+ value = PWRMGTCR0_AV_IDLE_PD_EN;
+
+ return sprintf(buf, %u\n, value ? 1 : 0);
+}
+
+static void do_store_altivec_idle(void *val)
+{
+
Re: [PATCH] powerpc/qe_lib: Share the qe_lib for the others architecture
On Mon, Oct 14, 2013 at 13:09 -0700, Greg Kroah-Hartman wrote: On Mon, Oct 14, 2013 at 02:40:44PM -0500, Kumar Gala wrote: Greg, Wondering your thoughts on drivers/qe vs something like drivers/soc/fsl/qe. The QuiccEngine (qe) is a communication core on some of the Freescale networking SoCs that provides the ability to do various networking/communication functionality. Channels on the QE can be used for various different things from ethernet, ATM, UART, or other functions. What makes the code QE specific? Are these devices that live on the QE bus, or are they controlling the QE controller? You may think of the QUICC as a programmable bitbang machine if you like. The very same component runs arbitrary and rather different protocols depending on how you setup its parameters. There have been serial controllers capable of different protocols like UART or SPI or I2S, but all of them are serial communication. There have been memory controllers which could bitbang different protocols (NAND, NOR/SRAM, DRAM), but all of them are memory. The QUICC is just a little more versatile, and appears to cover cases which reside in different Linux kernel subsystems (like: it's neither serial nor network exclusively, but can be either and potentially more). IIUC the question which Kumar Gala was asking is where to put code for the component which is neither a strict subset of any subsystem. Please correct me if I'm wrong. virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v11 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On Tue, Oct 08, 2013 at 04:22:07AM +0100, Hongbo Zhang wrote:
Hi Mark, Stephen and other DT maintainers?
The 1/3 had already been acked by Mark, and please have a further look
at this patch 2/3.
The DMA maintainer Vinod needs ack for the DT related patches so that
he can take all this patch set.
Sorry for the delay.
This looks ok to me.
Acked-by: Mark Rutland mark.rutl...@arm.com
On 09/26/2013 05:33 PM, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang hongbo.zh...@freescale.com
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch
adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
.../devicetree/bindings/powerpc/fsl/dma.txt| 70
+
arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 82
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 82
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
5 files changed, 238 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index 0584168..7fc1b01 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -128,6 +128,76 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ DMA controller which has same function as EloPlus except that Elo3 has 8
+ channels while EloPlus has only 4, it is used in Freescale Txxx and Bxxx
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include fsl,elo3-dma
+- reg : contains two entries for DMA General Status
Registers,
+ i.e. DGSR0 which includes status for channel 1~4, and
+ DGSR1 for channel 5~8
+- ranges: describes the mapping between the address space of
the
+ DMA channels and the address space of the DMA
controller
+
+- DMA channel nodes:
+- compatible: must include fsl,eloplus-dma-channel
+- reg : DMA channel specific registers
+- interrupts: interrupt specifier for DMA channel IRQ
+- interrupt-parent : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,elo3-dma;
+ reg = 0x100300 0x4,
+ 0x100600 0x4;
+ ranges = 0x0 0x100100 0x500;
+ dma-channel@0 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x0 0x80;
+ interrupts = 28 2 0 0;
+ };
+ dma-channel@80 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x80 0x80;
+ interrupts = 29 2 0 0;
+ };
+ dma-channel@100 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x100 0x80;
+ interrupts = 30 2 0 0;
+ };
+ dma-channel@180 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x180 0x80;
+ interrupts = 31 2 0 0;
+ };
+ dma-channel@300 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x300 0x80;
+ interrupts = 76 2 0 0;
+ };
+ dma-channel@380 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x380 0x80;
+ interrupts = 77 2 0 0;
+ };
+ dma-channel@400 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x400 0x80;
+ interrupts = 78 2 0 0;
+ };
+ dma-channel@480 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x480 0x80;
+ interrupts = 79 2 0 0;
+ };
+};
+
Note on DMA channel compatible properties: The compatible property must
say
fsl,elo-dma-channel or fsl,eloplus-dma-channel to be used by the Elo
DMA
driver (fsldma). Any DMA channel used by fsldma cannot be used by another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -223,13 +223,13 @@
reg = 0xe2000 0x1000;
};
-/include/ qoriq-dma-0.dtsi
+/include/ elo3-dma-0.dtsi
dma@100300 {
fsl,iommu-parent = pamu0;
fsl,liodn-reg = guts 0x580; /* DMA1LIODNR */
};
-/include/ qoriq-dma-1.dtsi
+/include/ elo3-dma-1.dtsi
dma@101300 {
Re: Perf not resolving all symbols, showing 0x7ffffxxx
I've tracked the start of the strange instruction pointers in 'perf report' to a commit by Anton: commit 75382aa72f06823db7312ad069c3bae2eb3f8548 Author: Anton Blanchard an...@samba.org Date: Tue Jun 26 01:01:36 2012 + powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs I don't know enough about PPC to know what's going on, but reverting the changes to perf_instruction_pointer() gets me reasonable 'perf report' output with 3.11. Thanks, mh On Thu, Oct 3, 2013 at 10:21 AM, Martin Hicks m...@bork.org wrote: Hi, I've been trying to track down a performance regression that started leading up to the v3.6 kernel, and while doing this I've been gathering perf data on v3.6-rc and comparing it to v3.11 perf reports of the same workload. With v3.6-rc kernels I get all symbols resolved like this: # Events: 39K cpu-clock-msecs # # Overhead Command Shared Object Symbol # ... .. # 9.69% nfsd [kernel.kallsyms] [k] csum_partial 5.64% nfsd [kernel.kallsyms] [k] __do_softirq 3.12% nfsd [sunrpc][k] svc_create 2.38% nfsd [kernel.kallsyms] [k] __queue_work 1.91% nfsd [gianfar_driver][k] gfar_poll 1.73% nfsd [kernel.kallsyms] [k] memset 1.54% nfsd [nfsd] [k] nfsd_vfs_read.isra.16 1.40% ksoftirqd/0 [kernel.kallsyms] [k] finish_task_switch.isra.54 1.30% nfsd [kernel.kallsyms] [k] get_page_from_freelist 1.21% nfsd [gianfar_driver][k] gfar_start_xmit 1.20% nfsd [sunrpc][k] svc_xprt_received But when I perf on v3.11 kernels I see a lot of unresolved symbols: # Events: 69K cpu-clock-msecs # # Overhead Command Shared Object Symbol # . ... # 73.80% nfsd [unknown] [k] 0x77fa 7.57% nfsd [kernel.kallsyms] [k] csum_partial 4.59% kworker/0:1 [unknown] [k] 0x7832 3.76% ksoftirqd/0 [unknown] [k] 0x796e 0.94% kswapd0 [unknown] [k] 0x7cc2 0.92% swapper [unknown] [k] 0x7a54 0.62% nfsd [kernel.kallsyms] [k] __udp4_lib_lookup 0.49% nfsd [kernel.kallsyms] [k] ip_append_page 0.48% nfsd [kernel.kallsyms] [k] __do_softirq 0.36% eventmon [unknown] [k] 0x79c4 0.32% nfsd [kernel.kallsyms] [k] __getnstimeofday Any ideas? Have I overlooked some necessary kernel config change? Does perf need some binary that I may not have installed on this embedded platform? Freescale mpc8379 (e300c4) Gcc-4.7.2 uClibC built with ct-ng 1.18.0 binutils 2.22 Thanks, mh -- Martin Hicks P.Eng. | m...@bork.org Bork Consulting Inc. | +1 (613) 266-2296 -- Martin Hicks P.Eng. | m...@bork.org Bork Consulting Inc. | +1 (613) 266-2296 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/3] iommu/fsl: Factor out PCI specific code.
-Original Message-
From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of Bjorn Helgaas
Sent: Tuesday, October 15, 2013 5:46 AM
To: Sethi Varun-B16395
Cc: Yoder Stuart-B08248; linux-ker...@vger.kernel.org; iommu@lists.linux-
foundation.org; Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH 1/3] iommu/fsl: Factor out PCI specific code.
On Sun, Oct 13, 2013 at 02:02:32AM +0530, Varun Sethi wrote:
Factor out PCI specific code in the PAMU driver.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
drivers/iommu/fsl_pamu_domain.c | 81 +++
1 file changed, 40 insertions(+), 41 deletions(-)
diff --git a/drivers/iommu/fsl_pamu_domain.c
b/drivers/iommu/fsl_pamu_domain.c index c857c30..e02e1de 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -677,13 +677,9 @@ static int handle_attach_device(struct
fsl_dma_domain *dma_domain,
return ret;
}
-static int fsl_pamu_attach_device(struct iommu_domain *domain,
- struct device *dev)
+static void check_for_pci_dma_device(struct device **dev)
check_for_pci_dma_device() doesn't give a good clue about what the
function returns. And why return something via a reference parameter
when you could return it directly?
[Sethi Varun-B16395] I will rename the function to get_dma_device and make it
return a pointer.
{
- struct fsl_dma_domain *dma_domain = domain-priv;
- const u32 *liodn;
- u32 liodn_cnt;
- int len, ret = 0;
+#ifdef CONFIG_PCI
struct pci_dev *pdev = NULL;
struct pci_controller *pci_ctl;
This is sort of a goofy looking function. It would read much better as
something like this:
[Sethi Varun-B16395] Will make the change.
struct device *dma_dev = dev;
#ifdef CONFIG_PCI
if (...) {
dma_dev = ...;
}
#endif
return dma_dev;
Does this need to care about reference counting when you return a pointer
to a different device?
[Sethi Varun-B16395] Reference counting isn't required, as we are just
obtaining the LIODN value from the PCI controller.
-Varun
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
On Fri, Oct 11, 2013 at 04:29:39PM -0400, Mark Lord wrote:
static int xx_alloc_msix_irqs(struct xx_dev *dev, int nvec)
{
nvec = roundup_pow_of_two(nvec);/* assume 0 nvec = 16 */
xx_disable_all_irqs(dev);
pci_lock_msi(dev-pdev);
rc = pci_get_msix_limit(dev-pdev, nvec);
if (rc 0)
goto err;
nvec = min(nvec, rc); /* if limit is more than requested */
nvec = rounddown_pow_of_two(nvec); /* (a) */
xx_prep_for_msix_vectors(dev, nvec);
rc = pci_enable_msix(dev-pdev, dev-irqs, nvec); /* (b) */
if (rc 0)
goto err;
pci_unlock_msi(dev-pdev);
dev-num_vectors = nvec;/* (b) */
return 0;
err:
pci_unlock_msi(dev-pdev);
kerr(dev-name, pci_enable_msix() failed, err=%d, rc);
dev-num_vectors = 0;
return rc;
}
That would still need a loop, to handle the natural race between
the calls to pci_get_msix_limit() and pci_enable_msix() -- the driver and
device
can and should fall back to a smaller number of vectors when
pci_enable_msix() fails.
Could you please explain why the value returned by pci_get_msix_limit()
might change before pci_enable_msix() returned, while both protected by
pci_lock_msi()?
Anyway, although the loop-free code (IMHO) reads better, pci_lock_msi()
it is not a part of the original proposal and the more I think about it
the less I like it.
--
Regards,
Alexander Gordeev
agord...@redhat.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Perf not resolving all symbols, showing 0x7ffffxxx
On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote: I've tracked the start of the strange instruction pointers in 'perf report' to a commit by Anton: commit 75382aa72f06823db7312ad069c3bae2eb3f8548 Author: Anton Blanchard an...@samba.org Date: Tue Jun 26 01:01:36 2012 + powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs I don't know enough about PPC to know what's going on, but reverting the changes to perf_instruction_pointer() gets me reasonable 'perf report' output with 3.11. This is an e300 core right ? (603...). Do that have an SIAR at all (Scott ?) Cheers, Ben. Thanks, mh On Thu, Oct 3, 2013 at 10:21 AM, Martin Hicks m...@bork.org wrote: Hi, I've been trying to track down a performance regression that started leading up to the v3.6 kernel, and while doing this I've been gathering perf data on v3.6-rc and comparing it to v3.11 perf reports of the same workload. With v3.6-rc kernels I get all symbols resolved like this: # Events: 39K cpu-clock-msecs # # Overhead Command Shared Object Symbol # ... .. # 9.69% nfsd [kernel.kallsyms] [k] csum_partial 5.64% nfsd [kernel.kallsyms] [k] __do_softirq 3.12% nfsd [sunrpc][k] svc_create 2.38% nfsd [kernel.kallsyms] [k] __queue_work 1.91% nfsd [gianfar_driver][k] gfar_poll 1.73% nfsd [kernel.kallsyms] [k] memset 1.54% nfsd [nfsd] [k] nfsd_vfs_read.isra.16 1.40% ksoftirqd/0 [kernel.kallsyms] [k] finish_task_switch.isra.54 1.30% nfsd [kernel.kallsyms] [k] get_page_from_freelist 1.21% nfsd [gianfar_driver][k] gfar_start_xmit 1.20% nfsd [sunrpc][k] svc_xprt_received But when I perf on v3.11 kernels I see a lot of unresolved symbols: # Events: 69K cpu-clock-msecs # # Overhead Command Shared Object Symbol # . ... # 73.80% nfsd [unknown] [k] 0x77fa 7.57% nfsd [kernel.kallsyms] [k] csum_partial 4.59% kworker/0:1 [unknown] [k] 0x7832 3.76% ksoftirqd/0 [unknown] [k] 0x796e 0.94% kswapd0 [unknown] [k] 0x7cc2 0.92% swapper [unknown] [k] 0x7a54 0.62% nfsd [kernel.kallsyms] [k] __udp4_lib_lookup 0.49% nfsd [kernel.kallsyms] [k] ip_append_page 0.48% nfsd [kernel.kallsyms] [k] __do_softirq 0.36% eventmon [unknown] [k] 0x79c4 0.32% nfsd [kernel.kallsyms] [k] __getnstimeofday Any ideas? Have I overlooked some necessary kernel config change? Does perf need some binary that I may not have installed on this embedded platform? Freescale mpc8379 (e300c4) Gcc-4.7.2 uClibC built with ct-ng 1.18.0 binutils 2.22 Thanks, mh -- Martin Hicks P.Eng. | m...@bork.org Bork Consulting Inc. | +1 (613) 266-2296 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] tty/hvc_console: Add DTR/RTS callback to handle HUPCL control
Hi Benjamin, On Sat, Oct 12, 2013 at 07:43:24AM +1100, Benjamin Herrenschmidt wrote: On Fri, 2013-10-11 at 14:47 +0200, Hendrik Brueckner wrote: The tiocmget/tiocmset callbacks are used to set and get modem status and triggered through an tty ioctl. The dtr_rts() callback is different and it is used for DTS/RTS handshaking between the hvc_console (or any other tty_port) and the tty layer. The tty port layer uses this callback to signal the hvc_console whether to raise or lower the DTR/RTS lines. This is different than the ioctl interface to controls the modem status. Well, DTR at least is the same via both callbacks... Also normal handshaking is normally RTS/CTS, only some HW setups hijacks DTR for RTS (old Macs come to mind). Yep. DTR is changed in both callbacks but from different layers. The tiocmget/tiocmset are triggered through the ioctl. The dtr_rts() callback is called in hvc_close() to properly handle HUPCL to lower modem control lines after last process closes the device (hang up). This is also done in the hvsilib_close() in hvsi_lib.c: /* Clear our own DTR */ if (!pv-tty || (pv-tty-termios.c_cflag HUPCL)) hvsilib_write_mctrl(pv, 0); This is actually what the dtr_rts() callback should trigger and I wonder whether it would be worth to introduce the dtr_rts() callback to encapsulate the hvsilib_write_mctrl(pv, 0); call from above. On the other hand, the dtr_rts() callback is a good encapsulation to not directly access the hp-tty to potentially prevent a layering violation. At least for the hvc_iucv() I do not want to deal with the underlying tty layer and introduce additional reference accounting. I hope this helps you to understand my rational for introducing the dtr_rts() callback. Thanks and kind regards, Hendrik ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc 8xx: Fixing memory init issue with CONFIG_PIN_TLB
Le 11/10/2013 17:13, Joakim Tjernlund a écrit : Linuxppc-dev linuxppc-dev-bounces+joakim.tjernlund=transmode...@lists.ozlabs.org wrote on 2013/10/11 14:56:40: Activating CONFIG_PIN_TLB allows access to the 24 first Mbytes of memory at bootup instead of 8. It is needed for big kernels for instance when activating CONFIG_LOCKDEP_SUPPORT. This needs to be taken into account in init_32 too, otherwise memory allocation soon fails after startup. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S linux-3.11/arch/powerpc/kernel/head_8xx.S --- linux-3.11.org/arch/powerpc/mm/init_32.c 2013-09-02 22:46:10.0 +0200 +++ linux-3.11/arch/powerpc/mm/init_32.c 2013-09-09 11:28:54.0 +0200 @@ -213,7 +213,12 @@ */ BUG_ON(first_memblock_base != 0); +#ifdef CONFIG_PIN_TLB + /* 8xx can only access 24MB at the moment */ + memblock_set_current_limit(min_t(u64, first_memblock_size, 0x0180)); +#else /* 8xx can only access 8MB at the moment */ memblock_set_current_limit(min_t(u64, first_memblock_size, 0x0080)); +#endif } #endif /* CONFIG_8xx */ hmm, I think you should always map 24 MB (or less if RAM 24 MB) and do the same in head_8xx.S. Or to keep it simple, just always map at least 16 MB here and in head_8xx.S, assuming that 16 MB is min RAM for any 8xx system running 3.x kernels. Yes we could do a more elaborated modification in the future. However it also has an impact on the boot loader, so I'm not sure we should make it the default without thinking twice. In the meantime, my patch does take into account the existing situation where you have 8Mb by default and 24Mb when you activate CONFIG_PIN_TLB. I see it as a bug fix and I believe we should include it at least in order to allow including in the stable releases. Do you see any issue with this approach ? Much of the need for pinning would go away if you adopted my 8MB pages from 2.4 to 3.x Jocke Christophe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc 8xx: Fixing memory init issue with CONFIG_PIN_TLB
leroy christophe christophe.le...@c-s.fr wrote on 2013/10/15 18:27:00: Le 11/10/2013 17:13, Joakim Tjernlund a écrit : Linuxppc-dev linuxppc-dev-bounces+joakim.tjernlund=transmode...@lists.ozlabs.org wrote on 2013/10/11 14:56:40: Activating CONFIG_PIN_TLB allows access to the 24 first Mbytes of memory at bootup instead of 8. It is needed for big kernels for instance when activating CONFIG_LOCKDEP_SUPPORT. This needs to be taken into account in init_32 too, otherwise memory allocation soon fails after startup. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S linux-3.11/arch/powerpc/kernel/head_8xx.S --- linux-3.11.org/arch/powerpc/mm/init_32.c 2013-09-02 22:46:10.0 +0200 +++ linux-3.11/arch/powerpc/mm/init_32.c 2013-09-09 11:28:54.0 +0200 @@ -213,7 +213,12 @@ */ BUG_ON(first_memblock_base != 0); +#ifdef CONFIG_PIN_TLB + /* 8xx can only access 24MB at the moment */ + memblock_set_current_limit(min_t(u64, first_memblock_size, 0x0180)); +#else /* 8xx can only access 8MB at the moment */ memblock_set_current_limit(min_t(u64, first_memblock_size, 0x0080)); +#endif } #endif /* CONFIG_8xx */ hmm, I think you should always map 24 MB (or less if RAM 24 MB) and do the same in head_8xx.S. Or to keep it simple, just always map at least 16 MB here and in head_8xx.S, assuming that 16 MB is min RAM for any 8xx system running 3.x kernels. Yes we could do a more elaborated modification in the future. However it also has an impact on the boot loader, so I'm not sure we should make it the default without thinking twice. In the meantime, my patch does take into account the existing situation where you have 8Mb by default and 24Mb when you activate CONFIG_PIN_TLB. I see it as a bug fix and I believe we should include it at least in order to allow including in the stable releases. Do you see any issue with this approach ? Not at all, so: Acked-by: Joakim Tjernlund joakim.tjernl...@transmode.se ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5] powerpc/mpc85xx: Update the clock nodes in device tree
On Mon, 2013-10-14 at 20:59 -0500, Tang Yuantian-B29983 wrote: -Original Message- From: Wood Scott-B07421 Sent: 2013年10月15日 星期二 6:13 To: Tang Yuantian-B29983 Cc: Wood Scott-B07421; Mark Rutland; devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Li Yang-Leo-R58472 Subject: Re: [PATCH v5] powerpc/mpc85xx: Update the clock nodes in device tree On Fri, 2013-10-11 at 21:52 -0500, Tang Yuantian-B29983 wrote: Thanks for your review. -Original Message- From: Wood Scott-B07421 Sent: 2013年10月12日 星期六 3:07 To: Mark Rutland Cc: Tang Yuantian-B29983; devicet...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org; Li Yang-Leo-R58472 Subject: Re: [PATCH v5] powerpc/mpc85xx: Update the clock nodes in device tree I'm not sure I understand the _0/_1 part, though. Doesn't each PLL just have one output, which the consumer may choose to divide by 2 (or in some cases 4)? Why does that division need to be exposed in the device tree as separate connections to the parent clock? The device tree makes that quite clear. You chose to model it that way in the device tree; that doesn't make it clear that the hardware works that way or that it's a good way to model it. Each PLL has several output which MUX node can take from. Point out where in the hardware documentation it says this. What I see is a PLL that has one output, and a MUX register that can choose from multiple PLL and divider options. Take T4240 for example: see section 4.6.5.1 , (Page 141) in T4240RM Rev. D, 09/2012. That shows the dividers as being somewhere in between the PLL and the MUX. The MUX is where the divider is selected. There's nothing in the PLL's programming interface that relates to the dividers. As such it's simpler to model it as being part of the MUX. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Perf not resolving all symbols, showing 0x7ffffxxx
On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote: I've tracked the start of the strange instruction pointers in 'perf report' to a commit by Anton: commit 75382aa72f06823db7312ad069c3bae2eb3f8548 Author: Anton Blanchard an...@samba.org Date: Tue Jun 26 01:01:36 2012 + powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs I don't know enough about PPC to know what's going on, but reverting the changes to perf_instruction_pointer() gets me reasonable 'perf report' output with 3.11. This is an e300 core right ? (603...). Do that have an SIAR at all (Scott ?) Yes, e300c3. mh -- Martin Hicks P.Eng. | m...@bork.org Bork Consulting Inc. | +1 (613) 266-2296 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Perf not resolving all symbols, showing 0x7ffffxxx
On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote: On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote: I've tracked the start of the strange instruction pointers in 'perf report' to a commit by Anton: commit 75382aa72f06823db7312ad069c3bae2eb3f8548 Author: Anton Blanchard an...@samba.org Date: Tue Jun 26 01:01:36 2012 + powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs I don't know enough about PPC to know what's going on, but reverting the changes to perf_instruction_pointer() gets me reasonable 'perf report' output with 3.11. This is an e300 core right ? (603...). Do that have an SIAR at all (Scott ?) Yes, e300c3. Ok so I have a hard time figuring out how that patch can make a difference since for all I can see, there is no perf backend upstream for e300 at all :-( I must certainly be missing something ... Scott, can you have a look ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Perf not resolving all symbols, showing 0x7ffffxxx
On Tue, 2013-10-15 at 14:53 -0500, Benjamin Herrenschmidt wrote: On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote: On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote: I've tracked the start of the strange instruction pointers in 'perf report' to a commit by Anton: commit 75382aa72f06823db7312ad069c3bae2eb3f8548 Author: Anton Blanchard an...@samba.org Date: Tue Jun 26 01:01:36 2012 + powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs I don't know enough about PPC to know what's going on, but reverting the changes to perf_instruction_pointer() gets me reasonable 'perf report' output with 3.11. This is an e300 core right ? (603...). Do that have an SIAR at all (Scott ?) Yes, e300c3. Ok so I have a hard time figuring out how that patch can make a difference since for all I can see, there is no perf backend upstream for e300 at all :-( I must certainly be missing something ... Scott, can you have a look ? e300c3 has a core-fsl-emb style performance monitor (though Linux doesn't support it yet). If a bug was bisected to a change in core-book3s.c, then it's probably a coincidence due to moving code around. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc 8xx: Fixing memory init issue with CONFIG_PIN_TLB
On Tue, 2013-10-15 at 18:27 +0200, leroy christophe wrote: Le 11/10/2013 17:13, Joakim Tjernlund a écrit : Linuxppc-dev linuxppc-dev-bounces+joakim.tjernlund=transmode...@lists.ozlabs.org wrote on 2013/10/11 14:56:40: Activating CONFIG_PIN_TLB allows access to the 24 first Mbytes of memory at bootup instead of 8. It is needed for big kernels for instance when activating CONFIG_LOCKDEP_SUPPORT. This needs to be taken into account in init_32 too, otherwise memory allocation soon fails after startup. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S linux-3.11/arch/powerpc/kernel/head_8xx.S --- linux-3.11.org/arch/powerpc/mm/init_32.c 2013-09-02 22:46:10.0 +0200 +++ linux-3.11/arch/powerpc/mm/init_32.c 2013-09-09 11:28:54.0 +0200 @@ -213,7 +213,12 @@ */ BUG_ON(first_memblock_base != 0); +#ifdef CONFIG_PIN_TLB + /* 8xx can only access 24MB at the moment */ + memblock_set_current_limit(min_t(u64, first_memblock_size, 0x0180)); +#else /* 8xx can only access 8MB at the moment */ memblock_set_current_limit(min_t(u64, first_memblock_size, 0x0080)); +#endif } #endif /* CONFIG_8xx */ hmm, I think you should always map 24 MB (or less if RAM 24 MB) and do the same in head_8xx.S. Or to keep it simple, just always map at least 16 MB here and in head_8xx.S, assuming that 16 MB is min RAM for any 8xx system running 3.x kernels. Yes we could do a more elaborated modification in the future. However it also has an impact on the boot loader, so I'm not sure we should make it the default without thinking twice. In the meantime, my patch does take into account the existing situation where you have 8Mb by default and 24Mb when you activate CONFIG_PIN_TLB. I see it as a bug fix and I believe we should include it at least in order to allow including in the stable releases. Do you see any issue with this approach ? The patch is fine, but I don't think it's stable material (BTW, if it were, you should have marked it as such when submitting). If I understand the situation correctly, there's no regression, and nothing fails to work with CONFIG_PIN_TLB that would have worked without it. It's just making CONFIG_PIN_TLB more useful. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Perf not resolving all symbols, showing 0x7ffffxxx
On Tue, 2013-10-15 at 15:22 -0500, Scott Wood wrote:
On Tue, 2013-10-15 at 14:53 -0500, Benjamin Herrenschmidt wrote:
On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:
On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote:
I've tracked the start of the strange instruction pointers in 'perf
report' to a commit by Anton:
commit 75382aa72f06823db7312ad069c3bae2eb3f8548
Author: Anton Blanchard an...@samba.org
Date: Tue Jun 26 01:01:36 2012 +
powerpc/perf: Move code to select SIAR or pt_regs into
perf_read_regs
I don't know enough about PPC to know what's going on, but reverting
the changes to perf_instruction_pointer() gets me reasonable 'perf
report' output with 3.11.
This is an e300 core right ? (603...). Do that have an SIAR at all
(Scott ?)
Yes, e300c3.
Ok so I have a hard time figuring out how that patch can make a
difference since for all I can see, there is no perf backend upstream
for e300 at all :-(
I must certainly be missing something ... Scott, can you have a look ?
e300c3 has a core-fsl-emb style performance monitor (though Linux
doesn't support it yet). If a bug was bisected to a change in
core-book3s.c, then it's probably a coincidence due to moving code
around.
Mort, can you see if just that change is enough to cause the problem ?
--- arch/powerpc/include/asm/perf_event.h
index 5c16b89..0bb2372 100644
@@ -26,8 +26,13 @@
#include asm/ptrace.h
#include asm/reg.h
+/*
+ * Overload regs-result to specify whether we should use the MSR (result
+ * is zero) or the SIAR (result is non zero).
+ */
#define perf_arch_fetch_caller_regs(regs, __ip)\
do {\
+ (regs)-result = 0; \
(regs)-nip = __ip; \
(regs)-gpr[1] = *(unsigned long *)__get_SP(); \
asm volatile(mfmsr %0 : =r ((regs)-msr)); \
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] tty/hvc_console: Add DTR/RTS callback to handle HUPCL control
On Tue, 2013-10-15 at 17:36 +0200, Hendrik Brueckner wrote: Hi Benjamin, On Sat, Oct 12, 2013 at 07:43:24AM +1100, Benjamin Herrenschmidt wrote: On Fri, 2013-10-11 at 14:47 +0200, Hendrik Brueckner wrote: The tiocmget/tiocmset callbacks are used to set and get modem status and triggered through an tty ioctl. The dtr_rts() callback is different and it is used for DTS/RTS handshaking between the hvc_console (or any other tty_port) and the tty layer. The tty port layer uses this callback to signal the hvc_console whether to raise or lower the DTR/RTS lines. This is different than the ioctl interface to controls the modem status. Well, DTR at least is the same via both callbacks... Also normal handshaking is normally RTS/CTS, only some HW setups hijacks DTR for RTS (old Macs come to mind). Yep. DTR is changed in both callbacks but from different layers. The tiocmget/tiocmset are triggered through the ioctl. The dtr_rts() callback is called in hvc_close() to properly handle HUPCL to lower modem control lines after last process closes the device (hang up). This is also done in the hvsilib_close() in hvsi_lib.c: /* Clear our own DTR */ if (!pv-tty || (pv-tty-termios.c_cflag HUPCL)) hvsilib_write_mctrl(pv, 0); This is actually what the dtr_rts() callback should trigger and I wonder whether it would be worth to introduce the dtr_rts() callback to encapsulate the hvsilib_write_mctrl(pv, 0); call from above. On the other hand, the dtr_rts() callback is a good encapsulation to not directly access the hp-tty to potentially prevent a layering violation. At least for the hvc_iucv() I do not want to deal with the underlying tty layer and introduce additional reference accounting. I hope this helps you to understand my rational for introducing the dtr_rts() callback. I'm not sure :) We still end up basically with 2 callbacks to do the same thing ... change the DTR line. It's odd at best, I still don't quite see why hvc_console couldn't just use mctrl... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 01/10] of/irq: Rework of_irq_count()
On Sun, 22 Sep 2013 16:19:27 -0500, Rob Herring robherri...@gmail.com wrote:
On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
thierry.red...@gmail.com wrote:
The of_irq_to_resource() helper that is used to implement of_irq_count()
tries to resolve interrupts and in fact creates a mapping for resolved
interrupts. That's pretty heavy lifting for something that claims to
just return the number of interrupts requested by a given device node.
Instead, use the more lightweight of_irq_map_one(), which, despite the
name, doesn't create an actual mapping. Perhaps a better name would be
of_irq_translate_one().
Signed-off-by: Thierry Reding tred...@nvidia.com
Acked-by: Rob Herring rob.herr...@calxeda.com
Applied (and fixed to match the of_irq_map_one -- of_irq_parse_one
rename that I'm going to merge in v3.13).
g.
---
drivers/of/irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 1752988..5f44388 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -368,9 +368,10 @@ EXPORT_SYMBOL_GPL(of_irq_to_resource);
*/
int of_irq_count(struct device_node *dev)
{
+ struct of_irq irq;
int nr = 0;
- while (of_irq_to_resource(dev, nr, NULL))
+ while (of_irq_map_one(dev, nr, irq) == 0)
nr++;
return nr;
--
1.8.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 01/10] of/irq: Rework of_irq_count()
On Sun, 22 Sep 2013 16:19:27 -0500, Rob Herring robherri...@gmail.com wrote:
On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
thierry.red...@gmail.com wrote:
The of_irq_to_resource() helper that is used to implement of_irq_count()
tries to resolve interrupts and in fact creates a mapping for resolved
interrupts. That's pretty heavy lifting for something that claims to
just return the number of interrupts requested by a given device node.
Instead, use the more lightweight of_irq_map_one(), which, despite the
name, doesn't create an actual mapping. Perhaps a better name would be
of_irq_translate_one().
Signed-off-by: Thierry Reding tred...@nvidia.com
Acked-by: Rob Herring rob.herr...@calxeda.com
Applied, thanks.
g.
---
drivers/of/irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 1752988..5f44388 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -368,9 +368,10 @@ EXPORT_SYMBOL_GPL(of_irq_to_resource);
*/
int of_irq_count(struct device_node *dev)
{
+ struct of_irq irq;
int nr = 0;
- while (of_irq_to_resource(dev, nr, NULL))
+ while (of_irq_map_one(dev, nr, irq) == 0)
nr++;
return nr;
--
1.8.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 04/10] irqdomain: Return errors from irq_create_of_mapping()
On Mon, 23 Sep 2013 10:13:38 +0200, Thierry Reding thierry.red...@gmail.com
wrote:
On Sun, Sep 22, 2013 at 04:14:43PM -0500, Rob Herring wrote:
On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
thierry.red...@gmail.com wrote:
Instead of returning 0 for all errors, allow the precise error code to
be propagated. This will be used in subsequent patches to allow further
propagation of error codes.
The interrupt number corresponding to the new mapping is returned in an
output parameter so that the return value is reserved to signal success
(== 0) or failure ( 0).
Signed-off-by: Thierry Reding tred...@nvidia.com
One comment below, otherwise:
Acked-by: Rob Herring rob.herr...@calxeda.com
diff --git a/arch/powerpc/kernel/pci-common.c
b/arch/powerpc/kernel/pci-common.c
index 905a24b..ae71b14 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -230,6 +230,7 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
{
struct of_irq oirq;
unsigned int virq;
+ int ret;
pr_debug(PCI: Try to map irq for %s...\n, pci_name(pci_dev));
@@ -266,8 +267,10 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
oirq.size, oirq.specifier[0], oirq.specifier[1],
of_node_full_name(oirq.controller));
- virq = irq_create_of_mapping(oirq.controller,
oirq.specifier,
-oirq.size);
+ ret = irq_create_of_mapping(oirq.controller,
oirq.specifier,
+ oirq.size, virq);
+ if (ret)
+ virq = NO_IRQ;
}
if(virq == NO_IRQ) {
pr_debug( Failed to map !\n);
Can you get rid of NO_IRQ usage here instead of adding to it.
I was trying to stay consistent with the remainder of the code. PowerPC
is a pretty heavy user of NO_IRQ. Of all 348 references, more than half
(182) are in arch/powerpc, so I'd rather like to get a go-ahead from
Benjamin on this.
That said, perhaps we should just go all the way and get rid of NO_IRQ
for good. Things could get somewhat messy, though. There are a couple of
these spread through the code:
#ifndef NO_IRQ
#define NO_IRQ (-1)
#endif
And all of them are wrong and need to be removed. :-) We're /slowly/
getting rid of the -1 and the usage of NO_IRQ. A global search and
replace of s/NO_IRQ/0/g can be very safely done on arch/powerpc since
powerpc has had NO_IRQ set correctly to '0' for a very long time now.
So, yes, if you're keen to do it I'd love to see a series getting rid of
more NO_IRQ users.
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 08/10] of/platform: Resolve interrupt references at probe time
On Wed, 18 Sep 2013 15:24:50 +0200, Thierry Reding thierry.red...@gmail.com
wrote:
Interrupt references are currently resolved very early (when a device is
created). This has the disadvantage that it will fail in cases where the
interrupt parent hasn't been probed and no IRQ domain for it has been
registered yet. To work around that various drivers use explicit
initcall ordering to force interrupt parents to be probed before devices
that need them are created. That's error prone and doesn't always work.
If a platform device uses an interrupt line connected to a different
platform device (such as a GPIO controller), both will be created in the
same batch, and the GPIO controller won't have been probed by its driver
when the depending platform device is created. Interrupt resolution will
fail in that case.
What is the reason for all the rework on the irq parsing return values?
A return value of '0' is always an error on irq parsing, regardless of
architecture even if NO_IRQ is defined as -1. I may have missed it, but
I don't see any checking for specific error values in the return paths
of the functions.
If the specific return value isn't required (and I don't think it is),
then you can simplify the whole series by getting rid of the rework
patches.
g.
Another common workaround is for drivers to explicitly resolve interrupt
references at probe time. This is suboptimal, however, because it will
require every driver to duplicate the code.
This patch adds support for late interrupt resolution to the platform
driver core, by resolving the references right before a device driver's
.probe() function will be called. This not only delays the resolution
until a much later time (giving interrupt parents a better chance of
being probed in the meantime), but it also allows the platform driver
core to queue the device for deferred probing if the interrupt parent
hasn't registered its IRQ domain yet.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Changes in v2:
- split off IRQ parsing into separate function to make code flow simpler
- add comments to point out some aspects of the implementation
- make code idempotent (as pointed out by Grygorii Strashko
drivers/base/platform.c | 4 ++
drivers/of/platform.c | 107
+---
include/linux/of_platform.h | 7 +++
3 files changed, 112 insertions(+), 6 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 4f8bef3..8dcf835 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -481,6 +481,10 @@ static int platform_drv_probe(struct device *_dev)
struct platform_device *dev = to_platform_device(_dev);
int ret;
+ ret = of_platform_probe(dev);
+ if (ret)
+ return ret;
+
if (ACPI_HANDLE(_dev))
acpi_dev_pm_attach(_dev, true);
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 9b439ac..df6d56e 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -142,7 +142,7 @@ struct platform_device *of_device_alloc(struct
device_node *np,
struct device *parent)
{
struct platform_device *dev;
- int rc, i, num_reg = 0, num_irq;
+ int rc, i, num_reg = 0;
struct resource *res, temp_res;
dev = platform_device_alloc(, -1);
@@ -153,23 +153,21 @@ struct platform_device *of_device_alloc(struct
device_node *np,
if (of_can_translate_address(np))
while (of_address_to_resource(np, num_reg, temp_res) == 0)
num_reg++;
- num_irq = of_irq_count(np);
/* Populate the resource table */
- if (num_irq || num_reg) {
- res = kzalloc(sizeof(*res) * (num_irq + num_reg), GFP_KERNEL);
+ if (num_reg) {
+ res = kzalloc(sizeof(*res) * num_reg, GFP_KERNEL);
if (!res) {
platform_device_put(dev);
return NULL;
}
- dev-num_resources = num_reg + num_irq;
+ dev-num_resources = num_reg;
dev-resource = res;
for (i = 0; i num_reg; i++, res++) {
rc = of_address_to_resource(np, i, res);
WARN_ON(rc);
}
- WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
}
dev-dev.of_node = of_node_get(np);
@@ -490,4 +488,101 @@ int of_platform_populate(struct device_node *root,
return rc;
}
EXPORT_SYMBOL_GPL(of_platform_populate);
+
+/**
+ * of_platform_parse_irq() - parse interrupt resource from device node
+ * @pdev: pointer to platform device
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+static int of_platform_parse_irq(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ unsigned int num_res = pdev-num_resources;
+
Re: [PATCH v11 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On 10/15/2013 09:38 PM, Mark Rutland wrote:
On Tue, Oct 08, 2013 at 04:22:07AM +0100, Hongbo Zhang wrote:
Hi Mark, Stephen and other DT maintainers?
The 1/3 had already been acked by Mark, and please have a further look
at this patch 2/3.
The DMA maintainer Vinod needs ack for the DT related patches so that
he can take all this patch set.
Sorry for the delay.
This looks ok to me.
Acked-by: Mark Rutland mark.rutl...@arm.com
Thanks, Mark.
On 09/26/2013 05:33 PM, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang hongbo.zh...@freescale.com
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
.../devicetree/bindings/powerpc/fsl/dma.txt| 70 +
arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 82
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 82
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
5 files changed, 238 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index 0584168..7fc1b01 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -128,6 +128,76 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ DMA controller which has same function as EloPlus except that Elo3 has 8
+ channels while EloPlus has only 4, it is used in Freescale Txxx and Bxxx
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include fsl,elo3-dma
+- reg : contains two entries for DMA General Status Registers,
+ i.e. DGSR0 which includes status for channel 1~4, and
+ DGSR1 for channel 5~8
+- ranges: describes the mapping between the address space of the
+ DMA channels and the address space of the DMA controller
+
+- DMA channel nodes:
+- compatible: must include fsl,eloplus-dma-channel
+- reg : DMA channel specific registers
+- interrupts: interrupt specifier for DMA channel IRQ
+- interrupt-parent : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,elo3-dma;
+ reg = 0x100300 0x4,
+ 0x100600 0x4;
+ ranges = 0x0 0x100100 0x500;
+ dma-channel@0 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x0 0x80;
+ interrupts = 28 2 0 0;
+ };
+ dma-channel@80 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x80 0x80;
+ interrupts = 29 2 0 0;
+ };
+ dma-channel@100 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x100 0x80;
+ interrupts = 30 2 0 0;
+ };
+ dma-channel@180 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x180 0x80;
+ interrupts = 31 2 0 0;
+ };
+ dma-channel@300 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x300 0x80;
+ interrupts = 76 2 0 0;
+ };
+ dma-channel@380 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x380 0x80;
+ interrupts = 77 2 0 0;
+ };
+ dma-channel@400 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x400 0x80;
+ interrupts = 78 2 0 0;
+ };
+ dma-channel@480 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x480 0x80;
+ interrupts = 79 2 0 0;
+ };
+};
+
Note on DMA channel compatible properties: The compatible property must say
fsl,elo-dma-channel or fsl,eloplus-dma-channel to be used by the Elo DMA
driver (fsldma). Any DMA channel used by fsldma cannot be used by another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -223,13 +223,13 @@
reg = 0xe2000 0x1000;
};
-/include/ qoriq-dma-0.dtsi
+/include/ elo3-dma-0.dtsi
dma@100300 {
fsl,iommu-parent = pamu0;
fsl,liodn-reg = guts 0x580; /* DMA1LIODNR */
};
-/include/ qoriq-dma-1.dtsi
+/include/ elo3-dma-1.dtsi
dma@101300 {
fsl,iommu-parent = pamu0;
fsl,liodn-reg = guts 0x584; /* DMA2LIODNR */
diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
[PATCH 01/10][v6] powerpc: Rename branch_opcode() to instr_opcode()
The logic used in branch_opcode() to extract the opcode for an instruction
applies to non branch instructions also. So rename to instr_opcode().
Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
---
arch/powerpc/lib/code-patching.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 17e5b23..2bc9db3 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -72,19 +72,19 @@ unsigned int create_cond_branch(const unsigned int *addr,
return instruction;
}
-static unsigned int branch_opcode(unsigned int instr)
+static unsigned int instr_opcode(unsigned int instr)
{
return (instr 26) 0x3F;
}
static int instr_is_branch_iform(unsigned int instr)
{
- return branch_opcode(instr) == 18;
+ return instr_opcode(instr) == 18;
}
static int instr_is_branch_bform(unsigned int instr)
{
- return branch_opcode(instr) == 16;
+ return instr_opcode(instr) == 16;
}
int instr_is_relative_branch(unsigned int instr)
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 00/10][v6] powerpc/perf: Export memory hierarchy level in Power7/8.
Power7 and Power8 processors save the memory hierarchy level (eg: L2, L3) from which a load or store instruction was satisfied. Export this hierarchy information to the user via the perf_mem_data_src object. Thanks to input from Stephane Eranian, Michael Ellerman, Michael Neuling and Anshuman Khandual. Sukadev Bhattiprolu (10): powerpc: Rename branch_opcode() to instr_opcode() powerpc/Power7: detect load/store instructions tools/perf: silence compiler warnings tools/perf: Remove local byteorder.h. powerpc/perf: Remove PME_ prefix for power7 events powerpc/perf: Export Power8 generic events in sysfs powerpc/perf: Add Power8 event PM_MRK_GRP_CMPL to sysfs. powerpc/perf: Define big-endian version of perf_mem_data_src powerpc/perf: Export Power8 memory hierarchy info to user space. powerpc/perf: Export Power7 memory hierarchy info to user space. arch/powerpc/include/asm/code-patching.h |1 + arch/powerpc/include/asm/perf_event_server.h |4 +- arch/powerpc/lib/code-patching.c | 51 +++- arch/powerpc/perf/core-book3s.c | 11 +++ arch/powerpc/perf/power7-pmu.c | 112 +++--- arch/powerpc/perf/power8-events-list.h | 21 + arch/powerpc/perf/power8-pmu.c | 97 -- include/uapi/linux/perf_event.h | 16 tools/perf/Makefile |1 - tools/perf/util/include/asm/byteorder.h |2 - tools/perf/util/include/linux/types.h| 20 + tools/perf/util/srcline.c|4 +- 12 files changed, 316 insertions(+), 24 deletions(-) create mode 100644 arch/powerpc/perf/power8-events-list.h delete mode 100644 tools/perf/util/include/asm/byteorder.h -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 04/10][v6] tools/perf: Remove local byteorder.h.
Remove the local tools/perf/util/include/asm/byteorder.h and add a few missing typedefs to tools/perf/util/include/linux/types.h. The local byteorder.h complicates defining big/little endian versions of data structures in include/uapi/linux/perf_event.h. Fix proposed by Michael Ellerman. Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com --- tools/perf/Makefile |1 - tools/perf/util/include/asm/byteorder.h |2 -- tools/perf/util/include/linux/types.h | 20 3 files changed, 20 insertions(+), 3 deletions(-) delete mode 100644 tools/perf/util/include/asm/byteorder.h diff --git a/tools/perf/Makefile b/tools/perf/Makefile index b62e12d..3c4a7d9 100644 --- a/tools/perf/Makefile +++ b/tools/perf/Makefile @@ -225,7 +225,6 @@ LIB_H += util/include/linux/types.h LIB_H += util/include/linux/linkage.h LIB_H += util/include/asm/asm-offsets.h LIB_H += util/include/asm/bug.h -LIB_H += util/include/asm/byteorder.h LIB_H += util/include/asm/hweight.h LIB_H += util/include/asm/swab.h LIB_H += util/include/asm/system.h diff --git a/tools/perf/util/include/asm/byteorder.h b/tools/perf/util/include/asm/byteorder.h deleted file mode 100644 index 2a9bdc0..000 --- a/tools/perf/util/include/asm/byteorder.h +++ /dev/null @@ -1,2 +0,0 @@ -#include asm/types.h -#include ../../../../include/uapi/linux/swab.h diff --git a/tools/perf/util/include/linux/types.h b/tools/perf/util/include/linux/types.h index eb46478..775f68e 100644 --- a/tools/perf/util/include/linux/types.h +++ b/tools/perf/util/include/linux/types.h @@ -7,10 +7,30 @@ #define __bitwise #endif +#ifndef __le16 +typedef __u16 __bitwise __le16; +#endif + #ifndef __le32 typedef __u32 __bitwise __le32; #endif +#ifndef __be16 +typedef __u16 __bitwise __be16; +#endif + +#ifndef __le64 +typedef __u64 __bitwise __le64; +#endif + +#ifndef __be32 +typedef __u32 __bitwise __be32; +#endif + +#ifndef __be64 +typedef __u64 __bitwise __be64; +#endif + #define DECLARE_BITMAP(name,bits) \ unsigned long name[BITS_TO_LONGS(bits)] -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 02/10][v6] powerpc/Power7: detect load/store instructions
Implement instr_is_load_store_2_06() to detect whether a given instruction
is one of the fixed-point or floating-point load/store instructions in the
POWER Instruction Set Architecture v2.06.
This function will be used in a follow-on patch to save memory hierarchy
information of the load/store on a Power7 system. (Power8 systems set some
bits in the SIER to identify load/store operations and hence don't need a
similar functionality).
Based on optimized code from Michael Ellerman and comments from Tom Musta.
Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
---
Changelog[v6]
- [Michael Ellerman, Tom Musta]: Optmize the implementation to
avoid for loop.
arch/powerpc/include/asm/code-patching.h |1 +
arch/powerpc/lib/code-patching.c | 45 ++
2 files changed, 46 insertions(+)
diff --git a/arch/powerpc/include/asm/code-patching.h
b/arch/powerpc/include/asm/code-patching.h
index a6f8c7a..9cc3ef1 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -34,6 +34,7 @@ int instr_is_branch_to_addr(const unsigned int *instr,
unsigned long addr);
unsigned long branch_target(const unsigned int *instr);
unsigned int translate_branch(const unsigned int *dest,
const unsigned int *src);
+int instr_is_load_store_2_06(const unsigned int *instr);
static inline unsigned long ppc_function_entry(void *func)
{
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 2bc9db3..49fb9d7 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -159,6 +159,51 @@ unsigned int translate_branch(const unsigned int *dest,
const unsigned int *src)
return 0;
}
+/*
+ * Determine if the op code in the instruction corresponds to a load or
+ * store instruction. Ignore the vector load instructions like evlddepx,
+ * evstddepx for now.
+ *
+ * This function is valid for POWER ISA 2.06.
+ *
+ * Reference: PowerISA_V2.06B_Public.pdf, Sections 3.3.2 through 3.3.6
+ * and 4.6.2 through 4.6.4, Appendix F (Opcode Maps).
+ */
+int instr_is_load_store_2_06(const unsigned int *instr)
+{
+ unsigned int op, upper, lower;
+
+ op = instr_opcode(*instr);
+
+ if ((op = 32 op = 58) || (op == 61 || op == 62))
+ return true;
+
+ if (op != 31)
+ return false;
+
+ upper = op 5;
+ lower = op 0x1f;
+
+ /* Short circuit as many misses as we can */
+ if (lower 3 || lower 23)
+ return false;
+
+ if (lower == 3) {
+ if (upper = 16)
+ return true;
+
+ return false;
+ }
+
+ if (lower == 7 || lower == 12)
+ return true;
+
+ if (lower = 20) /* lower = 23 (implicit) */
+ return true;
+
+ return false;
+}
+
#ifdef CONFIG_CODE_PATCHING_SELFTEST
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 03/10][v6] tools/perf: silence compiler warnings
The uninitialized variables cause warnings which are treated as errors
during build (without WERROR=0).
Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
---
tools/perf/util/srcline.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index 10983a9..0477055 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -223,8 +223,8 @@ out:
char *get_srcline(struct dso *dso, unsigned long addr)
{
- char *file;
- unsigned line;
+ char *file = NULL;
+ unsigned line = 0;
char *srcline;
char *dso_name = dso-long_name;
size_t size;
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 05/10][v6] powerpc/perf: Remove PME_ prefix for power7 events
We used the PME_ prefix earlier to avoid some macro/variable name
collisions. We have since changed the way we define/use the event
macros so we no longer need the prefix.
By dropping the prefix, we keep the the event macros consistent with
their official names.
Reported-by: Michael Ellerman eller...@au1.ibm.com
Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/perf_event_server.h |2 +-
arch/powerpc/perf/power7-pmu.c | 18 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/perf_event_server.h
b/arch/powerpc/include/asm/perf_event_server.h
index 3fd2f1b..d7b3419 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -138,7 +138,7 @@ extern ssize_t power_events_sysfs_show(struct device *dev,
#defineEVENT_PTR(_id, _suffix) EVENT_VAR(_id,
_suffix).attr.attr
#defineEVENT_ATTR(_name, _id, _suffix)
\
- PMU_EVENT_ATTR(_name, EVENT_VAR(_id, _suffix), PME_##_id, \
+ PMU_EVENT_ATTR(_name, EVENT_VAR(_id, _suffix), _id, \
power_events_sysfs_show)
#defineGENERIC_EVENT_ATTR(_name, _id) EVENT_ATTR(_name, _id, _g)
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index 56c67bc..ae24dfc 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -54,7 +54,7 @@
* Power7 event codes.
*/
#define EVENT(_name, _code) \
- PME_##_name = _code,
+ _name = _code,
enum {
#include power7-events-list.h
@@ -318,14 +318,14 @@ static void power7_disable_pmc(unsigned int pmc, unsigned
long mmcr[])
}
static int power7_generic_events[] = {
- [PERF_COUNT_HW_CPU_CYCLES] =PME_PM_CYC,
- [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = PME_PM_GCT_NOSLOT_CYC,
- [PERF_COUNT_HW_STALLED_CYCLES_BACKEND] =PME_PM_CMPLU_STALL,
- [PERF_COUNT_HW_INSTRUCTIONS] = PME_PM_INST_CMPL,
- [PERF_COUNT_HW_CACHE_REFERENCES] = PME_PM_LD_REF_L1,
- [PERF_COUNT_HW_CACHE_MISSES] = PME_PM_LD_MISS_L1,
- [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = PME_PM_BRU_FIN,
- [PERF_COUNT_HW_BRANCH_MISSES] = PME_PM_BR_MPRED,
+ [PERF_COUNT_HW_CPU_CYCLES] =PM_CYC,
+ [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = PM_GCT_NOSLOT_CYC,
+ [PERF_COUNT_HW_STALLED_CYCLES_BACKEND] =PM_CMPLU_STALL,
+ [PERF_COUNT_HW_INSTRUCTIONS] = PM_INST_CMPL,
+ [PERF_COUNT_HW_CACHE_REFERENCES] = PM_LD_REF_L1,
+ [PERF_COUNT_HW_CACHE_MISSES] = PM_LD_MISS_L1,
+ [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = PM_BRU_FIN,
+ [PERF_COUNT_HW_BRANCH_MISSES] = PM_BR_MPRED,
};
#define C(x) PERF_COUNT_HW_CACHE_##x
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 06/10][v6] powerpc/perf: Export Power8 generic events in sysfs
Export generic perf events for Power8 in sysfs.
Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
---
Changelog[v6]:
[Michael Ellerman] Drop PME_ prefix in macros
arch/powerpc/perf/power8-events-list.h | 20 +++
arch/powerpc/perf/power8-pmu.c | 44 +++-
2 files changed, 58 insertions(+), 6 deletions(-)
create mode 100644 arch/powerpc/perf/power8-events-list.h
diff --git a/arch/powerpc/perf/power8-events-list.h
b/arch/powerpc/perf/power8-events-list.h
new file mode 100644
index 000..1368547
--- /dev/null
+++ b/arch/powerpc/perf/power8-events-list.h
@@ -0,0 +1,20 @@
+/*
+ * Performance counter support for POWER8 processors.
+ *
+ * Copyright 2013 Sukadev Bhattiprolu, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+/*
+ * Some power8 event codes.
+ */
+EVENT(PM_CYC, 0x0001e)
+EVENT(PM_GCT_NOSLOT_CYC, 0x100f8)
+EVENT(PM_CMPLU_STALL, 0x4000a)
+EVENT(PM_INST_CMPL,0x2)
+EVENT(PM_BRU_FIN, 0x10068)
+EVENT(PM_BR_MPRED_CMPL,0x400f6)
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 2ee4a70..5141d97 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -18,13 +18,13 @@
/*
* Some power8 event codes.
*/
-#define PM_CYC 0x0001e
-#define PM_GCT_NOSLOT_CYC 0x100f8
-#define PM_CMPLU_STALL 0x4000a
-#define PM_INST_CMPL 0x2
-#define PM_BRU_FIN 0x10068
-#define PM_BR_MPRED_CMPL 0x400f6
+#define EVENT(_name, _code)_name = _code,
+enum {
+#include power8-events-list.h
+};
+
+#undef EVENT
/*
* Raw event encoding for POWER8:
@@ -510,6 +510,37 @@ static void power8_disable_pmc(unsigned int pmc, unsigned
long mmcr[])
mmcr[1] = ~(0xffUL MMCR1_PMCSEL_SHIFT(pmc + 1));
}
+GENERIC_EVENT_ATTR(cpu-cyles, PM_CYC);
+GENERIC_EVENT_ATTR(stalled-cycles-frontend,PM_GCT_NOSLOT_CYC);
+GENERIC_EVENT_ATTR(stalled-cycles-backend, PM_CMPLU_STALL);
+GENERIC_EVENT_ATTR(instructions, PM_INST_CMPL);
+GENERIC_EVENT_ATTR(branch-instructions,PM_BRU_FIN);
+GENERIC_EVENT_ATTR(branch-misses, PM_BR_MPRED_CMPL);
+
+#define EVENT(_name, _code)POWER_EVENT_ATTR(_name, _name);
+#include power8-events-list.h
+#undef EVENT
+
+#define EVENT(_name, _code)POWER_EVENT_PTR(_name),
+
+static struct attribute *power8_events_attr[] = {
+ GENERIC_EVENT_PTR(PM_CYC),
+ GENERIC_EVENT_PTR(PM_GCT_NOSLOT_CYC),
+ GENERIC_EVENT_PTR(PM_CMPLU_STALL),
+ GENERIC_EVENT_PTR(PM_INST_CMPL),
+ GENERIC_EVENT_PTR(PM_BRU_FIN),
+ GENERIC_EVENT_PTR(PM_BR_MPRED_CMPL),
+
+ #include power8-events-list.h
+ #undef EVENT
+ NULL
+};
+
+static struct attribute_group power8_pmu_events_group = {
+ .name = events,
+ .attrs = power8_events_attr,
+};
+
PMU_FORMAT_ATTR(event, config:0-49);
PMU_FORMAT_ATTR(pmcxsel, config:0-7);
PMU_FORMAT_ATTR(mark, config:8);
@@ -546,6 +577,7 @@ struct attribute_group power8_pmu_format_group = {
static const struct attribute_group *power8_pmu_attr_groups[] = {
power8_pmu_format_group,
+ power8_pmu_events_group,
NULL,
};
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 08/10][v6] powerpc/perf: Define big-endian version of perf_mem_data_src
perf_mem_data_src is an union that is initialized via the -val field
and accessed via the bitmap fields. For this to work on big endian
platforms, we also need a big-endian represenation of perf_mem_data_src.
Cc: Stephane Eranian eran...@google.com
Cc: Michael Ellerman mich...@ellerman.id.au
Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
---
Changelog [v6]
- [Michael Ellerman] Use __BIG_ENDIAN_BITFIELD to simplify the
endian check.
Changelog [v5]:
- perf_event.h includes byteorder.h which pulls in the local
byteorder.h when building the perf tool. This local byteorder.h
leaves __LITTLE_ENDIAN and __BIG_ENDIAN undefined.
Include endian.h explicitly in the local byteorder.h.
Changelog [v2]:
- [Vince Weaver, Michael Ellerman] No __KERNEL__ in uapi headers.
include/uapi/linux/perf_event.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index ca1d90b..383052b7 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -695,6 +695,7 @@ enum perf_callchain_context {
#define PERF_FLAG_FD_OUTPUT(1U 1)
#define PERF_FLAG_PID_CGROUP (1U 2) /* pid=cgroup id, per-cpu
mode only */
+#if defined(__LITTLE_ENDIAN_BITFIELD)
union perf_mem_data_src {
__u64 val;
struct {
@@ -706,6 +707,21 @@ union perf_mem_data_src {
mem_rsvd:31;
};
};
+#elif defined(__BIG_ENDIAN_BITFIELD)
+union perf_mem_data_src {
+ __u64 val;
+ struct {
+ __u64 mem_rsvd:31,
+ mem_dtlb:7, /* tlb access */
+ mem_lock:2, /* lock instr */
+ mem_snoop:5,/* snoop mode */
+ mem_lvl:14, /* memory hierarchy level */
+ mem_op:5; /* type of opcode */
+ };
+};
+#else
+#error Unknown endianness
+#endif
/* type of opcode (load/store/prefetch,code) */
#define PERF_MEM_OP_NA 0x01 /* not available */
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 09/10][v6] powerpc/perf: Export Power8 memory hierarchy info to user space.
On Power8, the LDST field in SIER identifies the memory hierarchy level
(eg: L1, L2 etc), from which a data-cache miss for a marked instruction
was satisfied.
Use the 'perf_mem_data_src' object to export this hierarchy level to user
space. Fortunately, the memory hierarchy levels in Power8 map fairly easily
into the arch-neutral levels as described by the ldst_src_map[] table.
Usage:
perf record -d -e 'cpu/PM_MRK_GRP_CMPL/' application
perf report -n --mem-mode --sort=mem,sym,dso,symbol_daddr,dso_daddr
For samples involving load/store instructions, the memory
hierarchy level is shown as L1 hit, Remote RAM hit etc.
# or
perf record --data application
perf report -D
Sample records contain a 'data_src' field which encodes the
memory hierarchy level: Eg: data_src 0x442 indicates
MEM_OP_LOAD, MEM_LVL_HIT, MEM_LVL_L2 (i.e load hit L2).
Note that the PMU event PM_MRK_GRP_CMPL tracks all marked group completions
events. While some of these are loads and stores, others like 'add'
instructions may also be sampled. One alternative of sampling on
PM_MRK_GRP_CMPL and throwing away non-loads and non-store samples could
yield an inconsistent profile of the application.
As the precise semantics of 'perf mem -t load' or 'perf mem -t store' (which
require sampling only loads or only stores) cannot be implemented on Power,
we don't implement 'perf mem' on Power for now.
Thanks to input from Stephane Eranian, Michael Ellerman and Michael Neuling.
Cc: Stephane Eranian eran...@google.com
Cc: Michael Ellerman mich...@ellerman.id.au
Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
---
Changelog[v2]:
Drop support for 'perf mem' for Power (use perf-record and perf-report
directly)
arch/powerpc/include/asm/perf_event_server.h |2 +
arch/powerpc/perf/core-book3s.c | 11 ++
arch/powerpc/perf/power8-pmu.c | 53 ++
3 files changed, 66 insertions(+)
diff --git a/arch/powerpc/include/asm/perf_event_server.h
b/arch/powerpc/include/asm/perf_event_server.h
index d7b3419..5f2c449 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -38,6 +38,8 @@ struct power_pmu {
void(*config_bhrb)(u64 pmu_bhrb_filter);
void(*disable_pmc)(unsigned int pmc, unsigned long mmcr[]);
int (*limited_pmc_event)(u64 event_id);
+ void(*get_mem_data_src)(union perf_mem_data_src *dsrc,
+ struct pt_regs *regs);
u32 flags;
const struct attribute_group**attr_groups;
int n_generic;
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index eeae308..5221ba1 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1696,6 +1696,13 @@ ssize_t power_events_sysfs_show(struct device *dev,
return sprintf(page, event=0x%02llx\n, pmu_attr-id);
}
+static inline void power_get_mem_data_src(union perf_mem_data_src *dsrc,
+ struct pt_regs *regs)
+{
+ if (ppmu-get_mem_data_src)
+ ppmu-get_mem_data_src(dsrc, regs);
+}
+
struct pmu power_pmu = {
.pmu_enable = power_pmu_enable,
.pmu_disable= power_pmu_disable,
@@ -1777,6 +1784,10 @@ static void record_and_restart(struct perf_event *event,
unsigned long val,
data.br_stack = cpuhw-bhrb_stack;
}
+ if (event-attr.sample_type PERF_SAMPLE_DATA_SRC
+ ppmu-get_mem_data_src)
+ ppmu-get_mem_data_src(data.data_src, regs);
+
if (perf_event_overflow(event, data, regs))
power_pmu_stop(event, 0);
}
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 5141d97..c25b5c3 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -541,6 +541,58 @@ static struct attribute_group power8_pmu_events_group = {
.attrs = power8_events_attr,
};
+#define POWER8_SIER_TYPE_SHIFT 15
+#define POWER8_SIER_TYPE_MASK (0x7LL POWER8_SIER_TYPE_SHIFT)
+
+#define POWER8_SIER_LDST_SHIFT 1
+#define POWER8_SIER_LDST_MASK (0x7LL POWER8_SIER_LDST_SHIFT)
+
+#define P(a, b)PERF_MEM_S(a, b)
+#define PLH(a, b) (P(OP, LOAD) | P(LVL, HIT) | P(a, b))
+#define PSM(a, b) (P(OP, STORE) | P(LVL, MISS) | P(a, b))
+
+/*
+ * Power8 interpretations:
+ * REM_CCE1: 1-hop indicates L2/L3 cache of a different core on same chip
+ * REM_CCE2: 2-hop indicates different chip or different node.
+ */
+static u64 ldst_src_map[] = {
+ /* 000 */ P(LVL, NA),
+
+ /* 001 */ PLH(LVL, L1),
+ /* 010 */ PLH(LVL, L2),
+
[PATCH 07/10][v6] powerpc/perf: Add Power8 event PM_MRK_GRP_CMPL to sysfs.
The perf event PM_MRK_GRP_CMPL is useful in analyzing memory hierarchy of applications. Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com --- Changelog[v6]: - [Michael Ellerman]: Drop redundant PME_ prefix from event name. arch/powerpc/perf/power8-events-list.h |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/perf/power8-events-list.h b/arch/powerpc/perf/power8-events-list.h index 1368547..b39e117 100644 --- a/arch/powerpc/perf/power8-events-list.h +++ b/arch/powerpc/perf/power8-events-list.h @@ -18,3 +18,4 @@ EVENT(PM_CMPLU_STALL, 0x4000a) EVENT(PM_INST_CMPL,0x2) EVENT(PM_BRU_FIN, 0x10068) EVENT(PM_BR_MPRED_CMPL,0x400f6) +EVENT(PM_MRK_GRP_CMPL, 0x40130) -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc, perf: Configure BHRB filter before enabling PMU interrupts
On 10/14/2013 11:49 AM, Michael Ellerman wrote: On Fri, Oct 11, 2013 at 10:02:28AM +0530, Anshuman Khandual wrote: On 10/11/2013 07:41 AM, Michael Ellerman wrote: On Thu, Oct 10, 2013 at 02:20:22PM +0530, Anshuman Khandual wrote: Even I think this is not right. Instruction sampling should have been enabled before we enable PMU interrupts. Else there is a small window of time where we could have the PMU enabled with events (which requires sampling) without the sampling itself being enabled in MMCRA. Yes I agree. That's a separate bug, which we'll need to test on all the book3s platforms we have perf support for. Okay, I guess any platform which supports sampling will definitely want to have it enabled before we can set the events to count on PMU. Can you think of any problem which can arise if we move it before the enabling the PMU back ? Else we can fix this easily. In theory it should be a trivial change. But hardware can behave in strange ways, it's possible on some old chip we need to do it the current way for some reason. So although I don't think it will be a problem, it could be, so we will need to test it thoroughly. So which are the HW chips, you would like to test this fix for possible problems ? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/2] Export POWER8 PMU raw event codes through sysfs
This patchset adds some missing event list for POWER7 PMU raw events which are exported through sysfs interface. Also adds a new set of raw PMU events list for POWER8. I have completed some amount of initial testing to verify the working of POWER8 raw event codes through sysfs. Before the patch directory contents: /sys/bus/event_source/devices/cpu/ format perf_event_mux_interval_ms power subsystem type uevent After the patch === (1) directory contents: /sys/bus/event_source/devices/cpu/ 'events' format perf_event_mux_interval_ms power subsystem type uevent (2) contents inside new directory: /sys/bus/event_source/devices/cpu/events/ PM_ANY_THRD_RUN_CYC PM_BR_2PATH PM_BR_CMPL PM_BR_MRK_2PATH PM_BR_TAKEN_CMPL PM_CMPLU_STALL_BRU PM_CMPLU_STALL_BRU_CRU PM_CMPLU_STALL_COQ_FULL PM_CMPLU_STALL_DCACHE_MISS PM_CMPLU_STALL_DMISS_L21_L31 PM_CMPLU_STALL_DMISS_L2L3 PM_CMPLU_STALL_DMISS_L2L3_CONFLICT PM_CMPLU_STALL_DMISS_L3MISS PM_CMPLU_STALL_DMISS_LMEM PM_CMPLU_STALL_DMISS_REMOTE PM_CMPLU_STALL_ERAT_MISS PM_CMPLU_STALL_FLUSH PM_CMPLU_STALL_FXLONG PM_CMPLU_STALL_FXU PM_CMPLU_STALL_HWSYNC PM_CMPLU_STALL_LOAD_FINISH ... Sample tests: perf stat -e 'cpu/PM_CMPLU_STALL_ERAT_MISS/' ls Performance counter stats for 'ls': 56762 cpu/PM_CMPLU_STALL_ERAT_MISS/ 0.003643785 seconds time elapsed perf stat -e 'cpu/PM_CMPLU_STALL_BRU/' ls Performance counter stats for 'ls': 208615 cpu/PM_CMPLU_STALL_BRU/ 0.003600713 seconds time elapsed = Anshuman Khandual (2): power7, perf: Make some new raw event codes available in sysfs power8, perf: Export raw event codes through sysfs interface arch/powerpc/perf/power7-events-list.h | 10 +++ arch/powerpc/perf/power8-events-list.h | 146 + arch/powerpc/perf/power8-pmu.c | 30 +++ 3 files changed, 186 insertions(+) create mode 100644 arch/powerpc/perf/power8-events-list.h -- 1.7.11.7 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] power8, perf: Export raw event codes through sysfs interface
This patch exports a set of POWER8 PMU raw event codes through sysfs interface. Right now the raw event set matches the entire set of POWER8 events found in libpfm4 library. Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com --- arch/powerpc/perf/power8-events-list.h | 146 + arch/powerpc/perf/power8-pmu.c | 30 +++ 2 files changed, 176 insertions(+) create mode 100644 arch/powerpc/perf/power8-events-list.h diff --git a/arch/powerpc/perf/power8-events-list.h b/arch/powerpc/perf/power8-events-list.h new file mode 100644 index 000..ee5b40e --- /dev/null +++ b/arch/powerpc/perf/power8-events-list.h @@ -0,0 +1,146 @@ +/* + * Performance counter support for POWER8 processors. + * + * Copyright 2013 Anshuman Khandual, IBM Corporation. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +EVENT(PM_1PLUS_PPC_CMPL, 0x04898) +EVENT(PM_1PLUS_PPC_DISP, 0x400f2) +EVENT(PM_ANY_THRD_RUN_CYC,0x100fa) +EVENT(PM_BR_TAKEN_CMPL, 0x200fa) +EVENT(PM_DATA_FROM_L2MISS,0x200fe) +EVENT(PM_DATA_FROM_L3MISS,0x300fe) +EVENT(PM_DATA_FROM_MEM, 0x400fe) +EVENT(PM_DTLB_MISS, 0x300fc) +EVENT(PM_EXT_INT, 0x200f8) +EVENT(PM_FLOP,0x100f4) +EVENT(PM_FLUSH, 0x400f8) +EVENT(PM_IERAT_MISS, 0x100f6) +EVENT(PM_INST_DISP, 0x200f2) +EVENT(PM_INST_FROM_L3MISS,0x300fa) +EVENT(PM_ITLB_MISS, 0x400fc) +EVENT(PM_L1_DCACHE_RELOAD_VALID, 0x300f6) +EVENT(PM_L1_ICACHE_MISS, 0x200fc) +EVENT(PM_LD_MISS_L1, 0x400f0) +EVENT(PM_LSU_DERAT_MISS, 0x200f6) +EVENT(PM_MRK_BR_MPRED_CMPL, 0x300e4) +EVENT(PM_MRK_BR_TAKEN_CMPL, 0x100e2) +EVENT(PM_MRK_DATA_FROM_L2MISS,0x400e8) +EVENT(PM_MRK_DATA_FROM_L3MISS,0x200e4) +EVENT(PM_MRK_DATA_FROM_MEM, 0x200e0) +EVENT(PM_MRK_DERAT_MISS, 0x300e6) +EVENT(PM_MRK_DTLB_MISS, 0x400e4) +EVENT(PM_MRK_INST_CMPL, 0x400e0) +EVENT(PM_MRK_INST_DISP, 0x100e0) +EVENT(PM_MRK_INST_FROM_L3MISS,0x400e6) +EVENT(PM_MRK_L1_ICACHE_MISS, 0x100e4) +EVENT(PM_MRK_L1_RELOAD_VALID, 0x100ea) +EVENT(PM_MRK_LD_MISS_L1, 0x200e2) +EVENT(PM_MRK_ST_CMPL, 0x300e2) +EVENT(PM_RUN_CYC, 0x600f4) +EVENT(PM_RUN_INST_CMPL, 0x500fa) +EVENT(PM_RUN_PURR,0x400f4) +EVENT(PM_ST_FIN, 0x200f0) +EVENT(PM_ST_MISS_L1, 0x300f0) +EVENT(PM_TB_BIT_TRANS,0x300f8) +EVENT(PM_THRD_CONC_RUN_INST, 0x300f4) +EVENT(PM_THRESH_EXC_1024, 0x300ea) +EVENT(PM_THRESH_EXC_128, 0x400ea) +EVENT(PM_THRESH_EXC_2048, 0x400ec) +EVENT(PM_THRESH_EXC_256, 0x100e8) +EVENT(PM_THRESH_EXC_32, 0x200e6) +EVENT(PM_THRESH_EXC_4096, 0x100e6) +EVENT(PM_THRESH_EXC_512, 0x200e8) +EVENT(PM_THRESH_EXC_64, 0x300e8) +EVENT(PM_THRESH_MET, 0x100ec) +EVENT(PM_BR_2PATH,0x40036) +EVENT(PM_BR_CMPL, 0x40060) +EVENT(PM_BR_MRK_2PATH,0x40138) +EVENT(PM_CMPLU_STALL_BRU, 0x4d018) +EVENT(PM_CMPLU_STALL_BRU_CRU, 0x2d018) +EVENT(PM_CMPLU_STALL_COQ_FULL,0x30026) +EVENT(PM_CMPLU_STALL_DCACHE_MISS, 0x2c012) +EVENT(PM_CMPLU_STALL_DMISS_L21_L31, 0x2c018) +EVENT(PM_CMPLU_STALL_DMISS_L2L3, 0x2c016) +EVENT(PM_CMPLU_STALL_DMISS_L2L3_CONFLICT, 0x4c016) +EVENT(PM_CMPLU_STALL_DMISS_L3MISS,0x4c01a) +EVENT(PM_CMPLU_STALL_DMISS_LMEM, 0x4c018) +EVENT(PM_CMPLU_STALL_DMISS_REMOTE,0x2c01c) +EVENT(PM_CMPLU_STALL_ERAT_MISS, 0x4c012) +EVENT(PM_CMPLU_STALL_FLUSH, 0x30038) +EVENT(PM_CMPLU_STALL_FXLONG, 0x4d016) +EVENT(PM_CMPLU_STALL_FXU, 0x2d016) +EVENT(PM_CMPLU_STALL_HWSYNC, 0x30036) +EVENT(PM_CMPLU_STALL_LOAD_FINISH, 0x4d014) +EVENT(PM_CMPLU_STALL_LSU, 0x2c010) +EVENT(PM_CMPLU_STALL_LWSYNC, 0x10036)
[PATCH 1/2] power7, perf: Make some new raw event codes available in sysfs
This patch adds some more raw event codes into the existing list of event codes present in power7-events-list.h file. This tries to complete the list of events supported in Power7 and matches the raw event list with libpfm4 library. Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com --- arch/powerpc/perf/power7-events-list.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/powerpc/perf/power7-events-list.h b/arch/powerpc/perf/power7-events-list.h index 687790a..64f13d9 100644 --- a/arch/powerpc/perf/power7-events-list.h +++ b/arch/powerpc/perf/power7-events-list.h @@ -546,3 +546,13 @@ EVENT(PM_MRK_DATA_FROM_RL2L3_SHR, 0x1d04c) EVENT(PM_DTLB_MISS_16M, 0x4c05e) EVENT(PM_LSU1_LMQ_LHR_MERGE, 0x0d09a) EVENT(PM_IFU_FIN, 0x40066) +EVENT(PM_1THRD_CON_RUN_INSTR, 0x30062) +EVENT(PM_CMPLU_STALL_COUNT, 0x4000B) +EVENT(PM_MEM0_PB_RD_CL, 0x30083) +EVENT(PM_THRD_1_RUN_CYC, 0x10060) +EVENT(PM_THRD_2_CONC_RUN_INSTR, 0x40062) +EVENT(PM_THRD_2_RUN_CYC, 0x20060) +EVENT(PM_THRD_3_CONC_RUN_INST,0x10062) +EVENT(PM_THRD_3_RUN_CYC, 0x30060) +EVENT(PM_THRD_4_CONC_RUN_INST,0x20062) +EVENT(PM_THRD_4_RUN_CYC, 0x40060) -- 1.7.11.7 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
