LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [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

* [PATCH 01/10][v6] powerpc: Rename branch_opcode() to instr_opcode()
From: Sukadev Bhattiprolu @ 2013-10-16  2:06 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: Michael Ellerman, linux-kernel, Stephane Eranian, linuxppc-dev,
	Paul Mackerras, Anshuman Khandual
In-Reply-To: <1381889202-16826-1-git-send-email-sukadev@linux.vnet.ibm.com>

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 <sukadev@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

^ permalink raw reply related

* [PATCH 00/10][v6] powerpc/perf: Export memory hierarchy level in Power7/8.
From: Sukadev Bhattiprolu @ 2013-10-16  2:06 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: Michael Ellerman, linux-kernel, Stephane Eranian, linuxppc-dev,
	Paul Mackerras, Anshuman Khandual

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

^ permalink raw reply

* [PATCH 02/10][v6] powerpc/Power7: detect load/store instructions
From: Sukadev Bhattiprolu @ 2013-10-16  2:06 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: Michael Ellerman, linux-kernel, Stephane Eranian, linuxppc-dev,
	Paul Mackerras, Anshuman Khandual
In-Reply-To: <1381889202-16826-1-git-send-email-sukadev@linux.vnet.ibm.com>

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 <sukadev@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

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox