* [PATCH v5 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define
From: Dongsheng Wang @ 2013-10-15 9:21 UTC (permalink / raw)
To: scottwood; +Cc: bharat.bhushan, linuxppc-dev, Wang Dongsheng
From: Wang Dongsheng <dongsheng.wang@freescale.com>
E6500 PVR and SPRN_PWRMGTCR0 will be used in subsequent pw20/altivec
idle patches.
Signed-off-by: Wang Dongsheng <dongsheng.wang@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 0x80200000
#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_L2CSR1 0x3FA /* 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 @@
#define CCR1_DPC 0x00000100 /* Disable L1 I-Cache/D-Cache parity checking */
#define CCR1_TCS 0x00000080 /* 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_SHIFT 16
+#define PWRMGTCR0_AV_IDLE_CNT 0x3F0000
+
/* Bit definitions for the MCSR. */
#define MCSR_MCS 0x80000000 /* Machine Check Summary */
#define MCSR_IB 0x40000000 /* Instruction PLB Error */
--
1.8.0
^ permalink raw reply related
* [PATCH v5 2/4] powerpc/85xx: add hardware automatically enter altivec idle state
From: Dongsheng Wang @ 2013-10-15 9:21 UTC (permalink / raw)
To: scottwood; +Cc: bharat.bhushan, linuxppc-dev, Wang Dongsheng
In-Reply-To: <1381828871-17110-1-git-send-email-dongsheng.wang@freescale.com>
From: Wang Dongsheng <dongsheng.wang@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.wang@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 */
+ oris r3, 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)
mflr r6
#ifdef CONFIG_PPC64
bl .setup_altivec_ivors
#endif
+ bl setup_altivec_idle
bl __setup_cpu_e5500
mtlr r6
blr
@@ -119,6 +139,7 @@ _GLOBAL(__setup_cpu_e5500)
_GLOBAL(__restore_cpu_e6500)
mflr r5
bl .setup_altivec_ivors
+ bl .setup_altivec_idle
bl __restore_cpu_e5500
mtlr r5
blr
--
1.8.0
^ permalink raw reply related
* [PATCH v5 3/4] powerpc/85xx: add hardware automatically enter pw20 state
From: Dongsheng Wang @ 2013-10-15 9:21 UTC (permalink / raw)
To: scottwood; +Cc: bharat.bhushan, linuxppc-dev, Wang Dongsheng
In-Reply-To: <1381828871-17110-1-git-send-email-dongsheng.wang@freescale.com>
From: Wang Dongsheng <dongsheng.wang@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.wang@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
mtlr r6
@@ -139,6 +159,7 @@ _GLOBAL(__setup_cpu_e5500)
_GLOBAL(__restore_cpu_e6500)
mflr r5
bl .setup_altivec_ivors
+ bl .setup_pw20_idle
bl .setup_altivec_idle
bl __restore_cpu_e5500
mtlr r5
--
1.8.0
^ permalink raw reply related
* [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Dongsheng Wang @ 2013-10-15 9:21 UTC (permalink / raw)
To: scottwood; +Cc: bharat.bhushan, linuxppc-dev, Wang Dongsheng
In-Reply-To: <1381828871-17110-1-git-send-email-dongsheng.wang@freescale.com>
From: Wang Dongsheng <dongsheng.wang@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.wang@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_BIT 63
+
+static u64 pw20_wt;
+static u64 altivec_idle_wt;
+
+static unsigned int get_idle_ticks_bit(u64 ns)
+{
+ u64 cycle;
+
+ if (ns >= 10000)
+ 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)
+{
+ u32 *value = val;
+ u32 altivec_idle;
+
+ altivec_idle = mfspr(SPRN_PWRMGTCR0);
+
+ if (*value)
+ altivec_idle |= PWRMGTCR0_AV_IDLE_PD_EN;
+ else
+ altivec_idle &= ~PWRMGTCR0_AV_IDLE_PD_EN;
+
+ mtspr(SPRN_PWRMGTCR0, altivec_idle);
+}
+
+static ssize_t store_altivec_idle(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_altivec_idle, &value, 1);
+
+ return count;
+}
+
+static ssize_t show_altivec_idle_wait_time(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ u32 value;
+ u64 tb_cycle;
+ s64 time;
+
+ unsigned int cpu = dev->id;
+
+ if (!altivec_idle_wt) {
+ smp_call_function_single(cpu, do_show_pwrmgtcr0, &value, 1);
+ value = (value & PWRMGTCR0_AV_IDLE_CNT) >>
+ PWRMGTCR0_AV_IDLE_CNT_SHIFT;
+
+ tb_cycle = (1 << (MAX_BIT - value)) * 2;
+ time = div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
+ } else {
+ time = altivec_idle_wt;
+ }
+
+ return sprintf(buf, "%llu\n", time > 0 ? time : 0);
+}
+
+static void set_altivec_idle_wait_entry_bit(void *val)
+{
+ u32 *value = val;
+ u32 altivec_idle;
+
+ altivec_idle = mfspr(SPRN_PWRMGTCR0);
+
+ /* Set Automatic AltiVec Idle Count */
+ /* clear count */
+ altivec_idle &= ~PWRMGTCR0_AV_IDLE_CNT;
+
+ /* set count */
+ altivec_idle |= ((MAX_BIT - *value) << PWRMGTCR0_AV_IDLE_CNT_SHIFT);
+
+ mtspr(SPRN_PWRMGTCR0, altivec_idle);
+}
+
+static ssize_t store_altivec_idle_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;
+
+ altivec_idle_wt = value;
+ smp_call_function_single(cpu, set_altivec_idle_wait_entry_bit,
+ &entry_bit, 1);
+
+ return count;
+}
+
+/*
+ * Enable/Disable interface:
+ * 0, disable. 1, enable.
+ */
+static DEVICE_ATTR(pw20_state, 0600, show_pw20_state, store_pw20_state);
+static DEVICE_ATTR(altivec_idle, 0600, show_altivec_idle, store_altivec_idle);
+
+/*
+ * Set wait time interface:(Nanosecond)
+ * 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]
+ * ...
+ */
+static DEVICE_ATTR(pw20_wait_time, 0600,
+ show_pw20_wait_time,
+ store_pw20_wait_time);
+static DEVICE_ATTR(altivec_idle_wait_time, 0600,
+ show_altivec_idle_wait_time,
+ store_altivec_idle_wait_time);
+#endif
+
/*
* Enabling PMCs will slow partition context switch times so we only do
* it the first time we write to the PMCs.
@@ -407,6 +685,15 @@ static void register_cpu_online(unsigned int cpu)
device_create_file(s, &dev_attr_pir);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+ if (PVR_VER(cur_cpu_spec->pvr_value) == PVR_VER_E6500) {
+ device_create_file(s, &dev_attr_pw20_state);
+ device_create_file(s, &dev_attr_pw20_wait_time);
+
+ device_create_file(s, &dev_attr_altivec_idle);
+ device_create_file(s, &dev_attr_altivec_idle_wait_time);
+ }
+#endif
cacheinfo_cpu_online(cpu);
}
@@ -479,6 +766,15 @@ static void unregister_cpu_online(unsigned int cpu)
device_remove_file(s, &dev_attr_pir);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+ if (PVR_VER(cur_cpu_spec->pvr_value) == PVR_VER_E6500) {
+ device_remove_file(s, &dev_attr_pw20_state);
+ device_remove_file(s, &dev_attr_pw20_wait_time);
+
+ device_remove_file(s, &dev_attr_altivec_idle);
+ device_remove_file(s, &dev_attr_altivec_idle_wait_time);
+ }
+#endif
cacheinfo_cpu_offline(cpu);
}
--
1.8.0
^ permalink raw reply related
* Re: [PATCH] powerpc/qe_lib: Share the qe_lib for the others architecture
From: Gerhard Sittig @ 2013-10-15 13:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org list, Xie Xiaobo,
Linux Kernel list
In-Reply-To: <20131014200952.GA20517@kroah.com>
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: office@denx.de
^ permalink raw reply
* Re: [PATCH v11 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: Mark Rutland @ 2013-10-15 13:38 UTC (permalink / raw)
To: Hongbo Zhang
Cc: devicetree@vger.kernel.org, ian.campbell@citrix.com, Pawel Moll,
swarren@wwwdotorg.org, vinod.koul@intel.com,
linux-kernel@vger.kernel.org, rob.herring@calxeda.com,
djbw@fb.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <52537A5F.7090802@freescale.com>
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.rutland@arm.com>
>
> On 09/26/2013 05:33 PM, hongbo.zhang@freescale.com wrote:
> > From: Hongbo Zhang <hongbo.zhang@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.zhang@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 b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
> > new file mode 100644
> > index 0000000..3c210e0
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
> > @@ -0,0 +1,82 @@
> > +/*
> > + * QorIQ Elo3 DMA device tree stub [ controller @ offset 0x100000 ]
> > + *
> > + * Copyright 2013 Freescale Semiconductor Inc.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions are met:
> > + * * Redistributions of source code must retain the above copyright
> > + * notice, this list of conditions and the following disclaimer.
> > + * * Redistributions in binary form must reproduce the above copyright
> > + * notice, this list of conditions and the following disclaimer in the
> > + * documentation and/or other materials provided with the distribution.
> > + * * Neither the name of Freescale Semiconductor nor the
> > + * names of its contributors may be used to endorse or promote products
> > + * derived from this software without specific prior written permission.
> > + *
> > + *
> > + * ALTERNATIVELY, this software may be distributed under the terms of the
> > + * GNU General Public License ("GPL") as published by the Free Software
> > + * Foundation, either version 2 of that License or (at your option) any
> > + * later version.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
> > + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> > + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> > + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
> > + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> > + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> > + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> > + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> > + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> > + */
> > +
> > +dma0: 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>;
> > + };
> > +};
> > diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
> > new file mode 100644
> > index 0000000..cccf3bb
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
> > @@ -0,0 +1,82 @@
> > +/*
> > + * QorIQ Elo3 DMA device tree stub [ controller @ offset 0x101000 ]
> > + *
> > + * Copyright 2013 Freescale Semiconductor Inc.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions are met:
> > + * * Redistributions of source code must retain the above copyright
> > + * notice, this list of conditions and the following disclaimer.
> > + * * Redistributions in binary form must reproduce the above copyright
> > + * notice, this list of conditions and the following disclaimer in the
> > + * documentation and/or other materials provided with the distribution.
> > + * * Neither the name of Freescale Semiconductor nor the
> > + * names of its contributors may be used to endorse or promote products
> > + * derived from this software without specific prior written permission.
> > + *
> > + *
> > + * ALTERNATIVELY, this software may be distributed under the terms of the
> > + * GNU General Public License ("GPL") as published by the Free Software
> > + * Foundation, either version 2 of that License or (at your option) any
> > + * later version.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
> > + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> > + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> > + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
> > + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> > + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> > + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> > + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> > + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> > + */
> > +
> > +dma1: dma@101300 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "fsl,elo3-dma";
> > + reg = <0x101300 0x4>,
> > + <0x101600 0x4>;
> > + ranges = <0x0 0x101100 0x500>;
> > + dma-channel@0 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x0 0x80>;
> > + interrupts = <32 2 0 0>;
> > + };
> > + dma-channel@80 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x80 0x80>;
> > + interrupts = <33 2 0 0>;
> > + };
> > + dma-channel@100 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x100 0x80>;
> > + interrupts = <34 2 0 0>;
> > + };
> > + dma-channel@180 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x180 0x80>;
> > + interrupts = <35 2 0 0>;
> > + };
> > + dma-channel@300 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x300 0x80>;
> > + interrupts = <80 2 0 0>;
> > + };
> > + dma-channel@380 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x380 0x80>;
> > + interrupts = <81 2 0 0>;
> > + };
> > + dma-channel@400 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x400 0x80>;
> > + interrupts = <82 2 0 0>;
> > + };
> > + dma-channel@480 {
> > + compatible = "fsl,eloplus-dma-channel";
> > + reg = <0x480 0x80>;
> > + interrupts = <83 2 0 0>;
> > + };
> > +};
> > diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> > index bd611a9..ec95c60 100644
> > --- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> > +++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> > @@ -387,8 +387,8 @@
> > reg = <0xea000 0x4000>;
> > };
> >
> > -/include/ "qoriq-dma-0.dtsi"
> > -/include/ "qoriq-dma-1.dtsi"
> > +/include/ "elo3-dma-0.dtsi"
> > +/include/ "elo3-dma-1.dtsi"
> >
> > /include/ "qoriq-espi-0.dtsi"
> > spi@110000 {
>
>
>
>
^ permalink raw reply
* Re: Perf not resolving all symbols, showing 0x7ffffxxx
From: Martin Hicks @ 2013-10-15 13:59 UTC (permalink / raw)
To: linuxppc-dev, Anton Blanchard
In-Reply-To: <CAJUS3Xn4tHKvDK8tzLw09+zsEAJHEScV2DbZhH9KkYL-5iCmUA@mail.gmail.com>
I've tracked the start of the strange instruction pointers in 'perf
report' to a commit by Anton:
commit 75382aa72f06823db7312ad069c3bae2eb3f8548
Author: Anton Blanchard <anton@samba.org>
Date: Tue Jun 26 01:01:36 2012 +0000
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 <mort@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] 0x7ffff7fa
> 7.57% nfsd [kernel.kallsyms] [k] csum_partial
> 4.59% kworker/0:1 [unknown] [k] 0x7ffff832
> 3.76% ksoftirqd/0 [unknown] [k] 0x7ffff96e
> 0.94% kswapd0 [unknown] [k] 0x7ffffcc2
> 0.92% swapper [unknown] [k] 0x7ffffa54
> 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] 0x7ffff9c4
> 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. | mort@bork.org
> Bork Consulting Inc. | +1 (613) 266-2296
--
Martin Hicks P.Eng. | mort@bork.org
Bork Consulting Inc. | +1 (613) 266-2296
^ permalink raw reply
* RE: [PATCH 1/3] iommu/fsl: Factor out PCI specific code.
From: Sethi Varun-B16395 @ 2013-10-15 14:35 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Wood Scott-B07421, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
Bhushan Bharat-R65777, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20131015001611.GA9203@google.com>
> -----Original Message-----
> From: iommu-bounces@lists.linux-foundation.org [mailto:iommu-
> bounces@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-kernel@vger.kernel.org; iommu@lists.linux-
> foundation.org; Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> dev@lists.ozlabs.org
> Subject: Re: [PATCH 1/3] iommu/fsl: Factor out PCI specific code.
>=20
> 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.Sethi@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)
>=20
> "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.
>=20
> > {
> > - struct fsl_dma_domain *dma_domain =3D domain->priv;
> > - const u32 *liodn;
> > - u32 liodn_cnt;
> > - int len, ret =3D 0;
> > +#ifdef CONFIG_PCI
> > struct pci_dev *pdev =3D NULL;
> > struct pci_controller *pci_ctl;
>=20
> This is sort of a goofy looking function. It would read much better as
> something like this:
>=20
[Sethi Varun-B16395] Will make the change.
> struct device *dma_dev =3D dev;
>=20
> #ifdef CONFIG_PCI
> if (...) {
> dma_dev =3D ...;
> }
> #endif
>=20
> return dma_dev;
>=20
> Does this need to care about reference counting when you return a pointer
> to a different device?
>=20
[Sethi Varun-B16395] Reference counting isn't required, as we are just obta=
ining the LIODN value from the PCI controller.
-Varun
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Alexander Gordeev @ 2013-10-15 15:30 UTC (permalink / raw)
To: Mark Lord
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, H. Peter Anvin,
linux-s390, Andy King, linux-scsi, linux-rdma, x86, Ingo Molnar,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Solarflare linux maintainers, netdev,
linux-kernel, Ralf Baechle, e1000-devel, Martin Schwidefsky,
linux390, linuxppc-dev
In-Reply-To: <52585FB3.7080508@start.ca>
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
agordeev@redhat.com
^ permalink raw reply
* Re: Perf not resolving all symbols, showing 0x7ffffxxx
From: Benjamin Herrenschmidt @ 2013-10-15 15:30 UTC (permalink / raw)
To: Martin Hicks; +Cc: Scott Wood, linuxppc-dev, Anton Blanchard
In-Reply-To: <CAJUS3X=LVHDMa+CTFS=O=F=DfU1=0cgcNzn-mEvXGaDXEZ+CBA@mail.gmail.com>
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 <anton@samba.org>
> Date: Tue Jun 26 01:01:36 2012 +0000
>
> 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 <mort@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] 0x7ffff7fa
> > 7.57% nfsd [kernel.kallsyms] [k] csum_partial
> > 4.59% kworker/0:1 [unknown] [k] 0x7ffff832
> > 3.76% ksoftirqd/0 [unknown] [k] 0x7ffff96e
> > 0.94% kswapd0 [unknown] [k] 0x7ffffcc2
> > 0.92% swapper [unknown] [k] 0x7ffffa54
> > 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] 0x7ffff9c4
> > 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. | mort@bork.org
> > Bork Consulting Inc. | +1 (613) 266-2296
>
>
>
^ permalink raw reply
* Re: [PATCH 1/2] tty/hvc_console: Add DTR/RTS callback to handle HUPCL control
From: Hendrik Brueckner @ 2013-10-15 15:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-s390, brueckner, gregkh, heiko.carstens, linuxppc-dev,
linux-kernel, Hendrik Brueckner, schwidefsky, jslaby
In-Reply-To: <1381524204.5630.91.camel@pasglop>
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
^ permalink raw reply
* Re: [PATCH] powerpc 8xx: Fixing memory init issue with CONFIG_PIN_TLB
From: leroy christophe @ 2013-10-15 16:27 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, linux-kernel, Paul Mackerras
In-Reply-To: <OFF3401910.4A8AA6D0-ONC1257C01.0052FC82-C1257C01.00539C55@transmode.se>
Le 11/10/2013 17:13, Joakim Tjernlund a écrit :
> "Linuxppc-dev"
> <linuxppc-dev-bounces+joakim.tjernlund=transmode.se@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.leroy@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.000000000 +0200
>> +++ linux-3.11/arch/powerpc/mm/init_32.c 2013-09-09 11:28:54.000000000
> +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,
> 0x01800000));
>> +#else
>> /* 8xx can only access 8MB at the moment */
>> memblock_set_current_limit(min_t(u64, first_memblock_size,
> 0x00800000));
>> +#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
^ permalink raw reply
* Re: [PATCH] powerpc 8xx: Fixing memory init issue with CONFIG_PIN_TLB
From: Joakim Tjernlund @ 2013-10-15 16:55 UTC (permalink / raw)
To: leroy christophe; +Cc: linuxppc-dev, linux-kernel, Paul Mackerras
In-Reply-To: <525D6CD4.5090403@c-s.fr>
leroy christophe <christophe.leroy@c-s.fr> wrote on 2013/10/15 18:27:00:
>=20
>=20
> Le 11/10/2013 17:13, Joakim Tjernlund a =E9crit :
> > "Linuxppc-dev"
> > <linuxppc-dev-bounces+joakim.tjernlund=3Dtransmode.se@lists.ozlabs.org>
> > wrote on 2013/10/11 14:56:40:
> >> Activating CONFIG=5FPIN=5FTLB 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=5FLOCKDEP=5FSUPPORT. This needs to be taken into account in=20
init=5F32
> > too,
> >> otherwise memory allocation soon fails after startup.
> >>
> >> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> >>
> >> diff -ur linux-3.11.org/arch/powerpc/kernel/head=5F8xx.S
> > linux-3.11/arch/powerpc/kernel/head=5F8xx.S
> >> --- linux-3.11.org/arch/powerpc/mm/init=5F32.c 2013-09-02
> > 22:46:10.000000000 +0200
> >> +++ linux-3.11/arch/powerpc/mm/init=5F32.c 2013-09-09=20
11:28:54.000000000
> > +0200
> >> @@ -213,7 +213,12 @@
> >> */
> >> BUG=5FON(first=5Fmemblock=5Fbase !=3D 0);
> >>
> >> +#ifdef CONFIG=5FPIN=5FTLB
> >> + /* 8xx can only access 24MB at the moment */
> >> + memblock=5Fset=5Fcurrent=5Flimit(min=5Ft(u64, first=5Fmemblock=5Fs=
ize,
> > 0x01800000));
> >> +#else
> >> /* 8xx can only access 8MB at the moment */
> >> memblock=5Fset=5Fcurrent=5Flimit(min=5Ft(u64, first=5Fmemblock=5F=
size,
> > 0x00800000));
> >> +#endif
> >> }
> >> #endif /* CONFIG=5F8xx */
> > hmm, I think you should always map 24 MB (or less if RAM < 24 MB) and=20
do
> > the same
> > in head=5F8xx.S.
> >
> > Or to keep it simple, just always map at least 16 MB here and in
> > head=5F8xx.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.
>=20
> In the meantime, my patch does take into account the existing situation=20
> where you have 8Mb by default and 24Mb when you activate CONFIG=5FPIN=5FT=
LB.
> I see it as a bug fix and I believe we should include it at least in=20
> order to allow including in the stable releases.
>=20
> Do you see any issue with this approach ?
Not at all, so:
Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
^ permalink raw reply
* Re: [PATCH v5] powerpc/mpc85xx: Update the clock nodes in device tree
From: Scott Wood @ 2013-10-15 17:40 UTC (permalink / raw)
To: Tang Yuantian-B29983
Cc: Mark Rutland, Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Li Yang-Leo-R58472, devicetree@vger.kernel.org
In-Reply-To: <D07C73A334FF604B95B3CBD2A545D07B150C2B08@039-SN2MPN1-013.039d.mgd.msft.net>
On Mon, 2013-10-14 at 20:59 -0500, Tang Yuantian-B29983 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: 2013=E5=B9=B410=E6=9C=8815=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=8C=
6:13
> > To: Tang Yuantian-B29983
> > Cc: Wood Scott-B07421; Mark Rutland; devicetree@vger.kernel.org;
> > linuxppc-dev@lists.ozlabs.org; Li Yang-Leo-R58472
> > Subject: Re: [PATCH v5] powerpc/mpc85xx: Update the clock nodes in de=
vice
> > tree
> >=20
> > 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=E5=B9=B410=E6=9C=8812=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=85=
=AD 3:07
> > > > To: Mark Rutland
> > > > Cc: Tang Yuantian-B29983; devicetree@vger.kernel.org; linuxppc-
> > > > dev@lists.ozlabs.org; Li Yang-Leo-R58472
> > > > Subject: Re: [PATCH v5] powerpc/mpc85xx: Update the clock nodes i=
n
> > > > device tree
> > > >
> > > > I'm not sure I understand the "_0"/"_1" part, though. Doesn't ea=
ch
> > > > 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 expose=
d
> > > > in the device tree as separate connections to the parent clock?
> > > >
> > > The device tree makes that quite clear.
> >=20
> > 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 mod=
el
> > it.
> >=20
> > > Each PLL has several output which MUX node can take from.
> >=20
> > Point out where in the hardware documentation it says this. What I s=
ee
> > is a PLL that has one output, and a MUX register that can choose from
> > multiple PLL and divider options.
> >=20
> 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
^ permalink raw reply
* Re: Perf not resolving all symbols, showing 0x7ffffxxx
From: Martin Hicks @ 2013-10-15 18:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev, Anton Blanchard
In-Reply-To: <1381851009.17841.14.camel@pasglop>
On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt
<benh@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 <anton@samba.org>
>> Date: Tue Jun 26 01:01:36 2012 +0000
>>
>> 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. | mort@bork.org
Bork Consulting Inc. | +1 (613) 266-2296
^ permalink raw reply
* Re: Perf not resolving all symbols, showing 0x7ffffxxx
From: Benjamin Herrenschmidt @ 2013-10-15 19:53 UTC (permalink / raw)
To: Martin Hicks; +Cc: Scott Wood, linuxppc-dev, Anton Blanchard
In-Reply-To: <CAJUS3XmN2WNJ1cnorb5vfas7mB6tdNLxuupFja=u_wYS=cxmdQ@mail.gmail.com>
On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:
> On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt
> <benh@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 <anton@samba.org>
> >> Date: Tue Jun 26 01:01:36 2012 +0000
> >>
> >> 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.
^ permalink raw reply
* Re: Perf not resolving all symbols, showing 0x7ffffxxx
From: Scott Wood @ 2013-10-15 20:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Martin Hicks, linuxppc-dev, Anton Blanchard
In-Reply-To: <1381866837.17841.21.camel@pasglop>
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
> > <benh@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 <anton@samba.org>
> > >> Date: Tue Jun 26 01:01:36 2012 +0000
> > >>
> > >> 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
^ permalink raw reply
* Re: [PATCH] powerpc 8xx: Fixing memory init issue with CONFIG_PIN_TLB
From: Scott Wood @ 2013-10-15 20:33 UTC (permalink / raw)
To: leroy christophe; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <525D6CD4.5090403@c-s.fr>
On Tue, 2013-10-15 at 18:27 +0200, leroy christophe wrote:
> Le 11/10/2013 17:13, Joakim Tjernlund a =C3=A9crit :
> > "Linuxppc-dev"
> > <linuxppc-dev-bounces+joakim.tjernlund=3Dtransmode.se@lists.ozlabs.or=
g>
> > wrote on 2013/10/11 14:56:40:
> >> Activating CONFIG_PIN_TLB allows access to the 24 first Mbytes of me=
mory
> > at
> >> bootup instead of 8. It is needed for "big" kernels for instance whe=
n
> > 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.leroy@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.000000000 +0200
> >> +++ linux-3.11/arch/powerpc/mm/init_32.c 2013-09-09 11:28:54.00000=
0000
> > +0200
> >> @@ -213,7 +213,12 @@
> >> */
> >> BUG_ON(first_memblock_base !=3D 0);
> >>
> >> +#ifdef CONFIG_PIN_TLB
> >> + /* 8xx can only access 24MB at the moment */
> >> + memblock_set_current_limit(min_t(u64, first_memblock_size,
> > 0x01800000));
> >> +#else
> >> /* 8xx can only access 8MB at the moment */
> >> memblock_set_current_limit(min_t(u64, first_memblock_size,
> > 0x00800000));
> >> +#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 i=
t=20
> also has an impact on the boot loader, so I'm not sure we should make i=
t=20
> the default without thinking twice.
>=20
> In the meantime, my patch does take into account the existing situation=
=20
> 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=20
> order to allow including in the stable releases.
>=20
> 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
^ permalink raw reply
* Re: Perf not resolving all symbols, showing 0x7ffffxxx
From: Benjamin Herrenschmidt @ 2013-10-15 20:39 UTC (permalink / raw)
To: Scott Wood; +Cc: Martin Hicks, linuxppc-dev, Anton Blanchard
In-Reply-To: <1381868527.7979.713.camel@snotra.buserror.net>
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
> > > <benh@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 <anton@samba.org>
> > > >> Date: Tue Jun 26 01:01:36 2012 +0000
> > > >>
> > > >> 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.
^ permalink raw reply
* Re: [PATCH 1/2] tty/hvc_console: Add DTR/RTS callback to handle HUPCL control
From: Benjamin Herrenschmidt @ 2013-10-15 20:47 UTC (permalink / raw)
To: Hendrik Brueckner
Cc: linux-s390, gregkh, heiko.carstens, linuxppc-dev, linux-kernel,
brueckner, schwidefsky, jslaby
In-Reply-To: <20131015153626.GA6129@linux.vnet.ibm.com>
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.
^ permalink raw reply
* Re: [PATCH v2 01/10] of/irq: Rework of_irq_count()
From: Grant Likely @ 2013-10-15 22:42 UTC (permalink / raw)
To: Rob Herring, Thierry Reding
Cc: devicetree@vger.kernel.org, Russell King, linux-mips,
Greg Kroah-Hartman, linux-kernel@vger.kernel.org, Rob Herring,
Ralf Baechle, sparclinux, Thomas Gleixner, linuxppc-dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAL_JsqLE8aj511oF-gK7Gu5QfmHsQO3+oJ0KFkv0wmuo7i6eiw@mail.gmail.com>
On Sun, 22 Sep 2013 16:19:27 -0500, Rob Herring <robherring2@gmail.com> wrote:
> On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
> <thierry.reding@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 <treding@nvidia.com>
>
> Acked-by: Rob Herring <rob.herring@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-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 01/10] of/irq: Rework of_irq_count()
From: Grant Likely @ 2013-10-15 22:55 UTC (permalink / raw)
To: Rob Herring, Thierry Reding
Cc: devicetree@vger.kernel.org, Russell King, linux-mips,
Greg Kroah-Hartman, linux-kernel@vger.kernel.org, Rob Herring,
Ralf Baechle, sparclinux, Thomas Gleixner, linuxppc-dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAL_JsqLE8aj511oF-gK7Gu5QfmHsQO3+oJ0KFkv0wmuo7i6eiw@mail.gmail.com>
On Sun, 22 Sep 2013 16:19:27 -0500, Rob Herring <robherring2@gmail.com> wrote:
> On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
> <thierry.reding@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 <treding@nvidia.com>
>
> Acked-by: Rob Herring <rob.herring@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-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 04/10] irqdomain: Return errors from irq_create_of_mapping()
From: Grant Likely @ 2013-10-15 23:01 UTC (permalink / raw)
To: Thierry Reding, Rob Herring, Benjamin Herrenschmidt
Cc: devicetree@vger.kernel.org, Russell King, linux-mips,
Greg Kroah-Hartman, linux-kernel@vger.kernel.org, Rob Herring,
Ralf Baechle, sparclinux, Thomas Gleixner, linuxppc-dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20130923081337.GB11881@ulmo>
On Mon, 23 Sep 2013 10:13:38 +0200, Thierry Reding <thierry.reding@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.reding@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 <treding@nvidia.com>
> >
> > One comment below, otherwise:
> >
> > Acked-by: Rob Herring <rob.herring@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.
^ permalink raw reply
* Re: [PATCH v2 08/10] of/platform: Resolve interrupt references at probe time
From: Grant Likely @ 2013-10-15 23:24 UTC (permalink / raw)
To: Thierry Reding, Rob Herring, Greg Kroah-Hartman, Thomas Gleixner
Cc: linux-mips, Russell King, devicetree, linux-kernel, Ralf Baechle,
sparclinux, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1379510692-32435-9-git-send-email-treding@nvidia.com>
On Wed, 18 Sep 2013 15:24:50 +0200, Thierry Reding <thierry.reding@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 <treding@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;
> + struct resource *res = pdev->resource;
> + unsigned int num_irq, num, c;
> + int ret = 0;
> +
> + num_irq = of_irq_count(pdev->dev.of_node);
> + if (!num_irq)
> + return 0;
> +
> + /*
> + * Deferred probing may cause this function to be called multiple
> + * times, so check if all interrupts have been parsed already and
> + * return early.
> + */
> + for (c = 0; c < num_irq; c++)
> + if (platform_get_irq(pdev, c) < 0)
> + break;
> +
> + if (c == num_irq)
> + return 0;
> +
> + num = num_res + num_irq;
> +
> + /*
> + * Note that in case we're called twice on the same device (due to
> + * deferred probing for example) this will simply be a nop because
> + * krealloc() returns the input pointer if the size of the memory
> + * block that it points to is larger than or equal to the new size
> + * being requested.
> + */
> + res = krealloc(res, num * sizeof(*res), GFP_KERNEL);
> + if (!res)
> + return -ENOMEM;
> +
> + pdev->resource = res;
> + res += num_res;
> +
> + /*
> + * It is possible for this to fail. If so, not that the number of
> + * resources is not updated, so that the next call to this function
> + * will parse all interrupts again. Otherwise we can't keep track of
> + * how many we've parsed so far.
> + */
> + ret = of_irq_to_resource_table(np, res, num_irq);
> + if (ret < 0)
> + return ret;
> +
> + /*
> + * All interrupts are guaranteed to have been parsed and stored in
> + * the resource table, so the number of resources can now safely be
> + * updated.
> + */
> + pdev->num_resources += num_irq;
> +
> + return 0;
> +}
> +
> +/**
> + * of_platform_probe() - OF specific initialization at probe time
> + * @pdev: pointer to a platform device
> + *
> + * This function is called by the driver core to perform devicetree-specific
> + * setup for a given platform device at probe time. If a device's resources
> + * as specified in the device tree are not available yet, this function can
> + * return -EPROBE_DEFER and cause the device to be probed again later, when
> + * other drivers that potentially provide the missing resources have been
> + * probed in turn.
> + *
> + * Note that because of the above, all code executed by this function must
> + * be prepared to be run multiple times on the same device (i.e. it must be
> + * idempotent).
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int of_platform_probe(struct platform_device *pdev)
> +{
> + int ret;
> +
> + if (!pdev->dev.of_node)
> + return 0;
> +
> + ret = of_platform_parse_irq(pdev);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> #endif /* CONFIG_OF_ADDRESS */
> diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
> index 05cb4a9..92fc4f6 100644
> --- a/include/linux/of_platform.h
> +++ b/include/linux/of_platform.h
> @@ -72,6 +72,8 @@ extern int of_platform_populate(struct device_node *root,
> const struct of_device_id *matches,
> const struct of_dev_auxdata *lookup,
> struct device *parent);
> +
> +extern int of_platform_probe(struct platform_device *pdev);
> #else
> static inline int of_platform_populate(struct device_node *root,
> const struct of_device_id *matches,
> @@ -80,6 +82,11 @@ static inline int of_platform_populate(struct device_node *root,
> {
> return -ENODEV;
> }
> +
> +static inline int of_platform_probe(struct platform_device *pdev)
> +{
> + return 0;
> +}
> #endif
>
> #endif /* _LINUX_OF_PLATFORM_H */
> --
> 1.8.4
>
^ permalink raw reply
* Re: [PATCH v11 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: Hongbo Zhang @ 2013-10-16 1:59 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree@vger.kernel.org, ian.campbell@citrix.com, Pawel Moll,
swarren@wwwdotorg.org, vinod.koul@intel.com,
linux-kernel@vger.kernel.org, rob.herring@calxeda.com,
djbw@fb.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20131015133849.GH19196@e106331-lin.cambridge.arm.com>
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.rutland@arm.com>
Thanks, Mark.
>> On 09/26/2013 05:33 PM, hongbo.zhang@freescale.com wrote:
>>> From: Hongbo Zhang <hongbo.zhang@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.zhang@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 b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
>>> new file mode 100644
>>> index 0000000..3c210e0
>>> --- /dev/null
>>> +++ b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
>>> @@ -0,0 +1,82 @@
>>> +/*
>>> + * QorIQ Elo3 DMA device tree stub [ controller @ offset 0x100000 ]
>>> + *
>>> + * Copyright 2013 Freescale Semiconductor Inc.
>>> + *
>>> + * Redistribution and use in source and binary forms, with or without
>>> + * modification, are permitted provided that the following conditions are met:
>>> + * * Redistributions of source code must retain the above copyright
>>> + * notice, this list of conditions and the following disclaimer.
>>> + * * Redistributions in binary form must reproduce the above copyright
>>> + * notice, this list of conditions and the following disclaimer in the
>>> + * documentation and/or other materials provided with the distribution.
>>> + * * Neither the name of Freescale Semiconductor nor the
>>> + * names of its contributors may be used to endorse or promote products
>>> + * derived from this software without specific prior written permission.
>>> + *
>>> + *
>>> + * ALTERNATIVELY, this software may be distributed under the terms of the
>>> + * GNU General Public License ("GPL") as published by the Free Software
>>> + * Foundation, either version 2 of that License or (at your option) any
>>> + * later version.
>>> + *
>>> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
>>> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
>>> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
>>> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
>>> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
>>> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
>>> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
>>> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>>> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
>>> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>>> + */
>>> +
>>> +dma0: 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>;
>>> + };
>>> +};
>>> diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
>>> new file mode 100644
>>> index 0000000..cccf3bb
>>> --- /dev/null
>>> +++ b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
>>> @@ -0,0 +1,82 @@
>>> +/*
>>> + * QorIQ Elo3 DMA device tree stub [ controller @ offset 0x101000 ]
>>> + *
>>> + * Copyright 2013 Freescale Semiconductor Inc.
>>> + *
>>> + * Redistribution and use in source and binary forms, with or without
>>> + * modification, are permitted provided that the following conditions are met:
>>> + * * Redistributions of source code must retain the above copyright
>>> + * notice, this list of conditions and the following disclaimer.
>>> + * * Redistributions in binary form must reproduce the above copyright
>>> + * notice, this list of conditions and the following disclaimer in the
>>> + * documentation and/or other materials provided with the distribution.
>>> + * * Neither the name of Freescale Semiconductor nor the
>>> + * names of its contributors may be used to endorse or promote products
>>> + * derived from this software without specific prior written permission.
>>> + *
>>> + *
>>> + * ALTERNATIVELY, this software may be distributed under the terms of the
>>> + * GNU General Public License ("GPL") as published by the Free Software
>>> + * Foundation, either version 2 of that License or (at your option) any
>>> + * later version.
>>> + *
>>> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
>>> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
>>> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
>>> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
>>> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
>>> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
>>> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
>>> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>>> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
>>> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>>> + */
>>> +
>>> +dma1: dma@101300 {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + compatible = "fsl,elo3-dma";
>>> + reg = <0x101300 0x4>,
>>> + <0x101600 0x4>;
>>> + ranges = <0x0 0x101100 0x500>;
>>> + dma-channel@0 {
>>> + compatible = "fsl,eloplus-dma-channel";
>>> + reg = <0x0 0x80>;
>>> + interrupts = <32 2 0 0>;
>>> + };
>>> + dma-channel@80 {
>>> + compatible = "fsl,eloplus-dma-channel";
>>> + reg = <0x80 0x80>;
>>> + interrupts = <33 2 0 0>;
>>> + };
>>> + dma-channel@100 {
>>> + compatible = "fsl,eloplus-dma-channel";
>>> + reg = <0x100 0x80>;
>>> + interrupts = <34 2 0 0>;
>>> + };
>>> + dma-channel@180 {
>>> + compatible = "fsl,eloplus-dma-channel";
>>> + reg = <0x180 0x80>;
>>> + interrupts = <35 2 0 0>;
>>> + };
>>> + dma-channel@300 {
>>> + compatible = "fsl,eloplus-dma-channel";
>>> + reg = <0x300 0x80>;
>>> + interrupts = <80 2 0 0>;
>>> + };
>>> + dma-channel@380 {
>>> + compatible = "fsl,eloplus-dma-channel";
>>> + reg = <0x380 0x80>;
>>> + interrupts = <81 2 0 0>;
>>> + };
>>> + dma-channel@400 {
>>> + compatible = "fsl,eloplus-dma-channel";
>>> + reg = <0x400 0x80>;
>>> + interrupts = <82 2 0 0>;
>>> + };
>>> + dma-channel@480 {
>>> + compatible = "fsl,eloplus-dma-channel";
>>> + reg = <0x480 0x80>;
>>> + interrupts = <83 2 0 0>;
>>> + };
>>> +};
>>> diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
>>> index bd611a9..ec95c60 100644
>>> --- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
>>> +++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
>>> @@ -387,8 +387,8 @@
>>> reg = <0xea000 0x4000>;
>>> };
>>>
>>> -/include/ "qoriq-dma-0.dtsi"
>>> -/include/ "qoriq-dma-1.dtsi"
>>> +/include/ "elo3-dma-0.dtsi"
>>> +/include/ "elo3-dma-1.dtsi"
>>>
>>> /include/ "qoriq-espi-0.dtsi"
>>> spi@110000 {
>>
>>
>>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox