Re: [RFC PATCH 16/16] KVM: PPC: e500mc support
On 01/09/2012 09:29 PM, Scott Wood wrote: Best to include their signoffs, if possible. These patches are based in part on a bunch of different patches from these people (for which I did receive signoffs). I was reluctant to put their signoff directly on the new patches, since I didn't want to make it look like they had submitted the patch in anything resembling its current form. I wanted to give them credit for what they did, but not blame for what I did with their code. Signoffs are for assigning neither credit nor blame, but for attributing authorship and affirming that a contributor has the right to contribute code or pass it along. Please read the DCO at https://lwn.net/Articles/437739/. It's okay to miss them from time to time, especially for established contributors, but avoid it whenever possible. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 00/14] DMA-mapping framework redesign preparation
Hello, To help everyone in testing and adapting our patches for his hardware platform I've rebased our patches onto the latest v3.2 Linux kernel and prepared a few GIT branches in our public repository. These branches contain our memory management related patches posted in the following threads: [PATCHv18 0/11] Contiguous Memory Allocator: http://www.spinics.net/lists/linux-mm/msg28125.html later called CMAv18, [PATCH 00/14] DMA-mapping framework redesign preparation: http://www.spinics.net/lists/linux-sh/msg09777.html and [PATCH 0/8 v4] ARM: DMA-mapping framework redesign: http://www.spinics.net/lists/arm-kernel/msg151147.html with the following update: http://www.spinics.net/lists/arm-kernel/msg154889.html later called DMAv5. These branches are available in our public GIT repository: git://git.infradead.org/users/kmpark/linux-samsung http://git.infradead.org/users/kmpark/linux-samsung/ The following branches are available: 1) 3.2-cma-v18 Vanilla Linux v3.2 with fixed CMA v18 patches (first patch replaced with the one from v17 to fix SMP issues, see the respective thread). 2) 3.2-dma-v5 Vanilla Linux v3.2 + iommu/next (IOMMU maintainer's patches) branch with DMA-preparation and DMA-mapping framework redesign patches. 3) 3.2-cma-v18-dma-v5 Previous two branches merged together (DMA-mapping on top of CMA) 4) 3.2-cma-v18-dma-v5-exynos Previous branch rebased on top of iommu/next + kgene/for-next (Samsung SoC platform maintainer's patches) with new Exynos4 IOMMU driver by KyongHo Cho and relevant glue code. 5) 3.2-dma-v5-exynos Branch from point 2 rebased on top of iommu/next + kgene/for-next (Samsung SoC maintainer's patches) with new Exynos4 IOMMU driver by KyongHo Cho and relevant glue code. I hope everyone will find a branch that suits his needs. :) Best regards -- Marek Szyprowski Samsung Poland RD Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] of: Change logic to overwrite cmd_line with CONFIG_CMDLINE
On Fri, 2012-01-06 at 16:48 -0800, Doug Anderson wrote: I know this is a long-dead thread, but I was a little curious about the motivation here. Hi ! Sorry, I planned to reply earlier and then forgot about it... I'm looking at trying to support CONFIG_CMDLINE_EXTEND (an ARM Kconfig) in this function and don't know in which cases I should look at the CONFIG_CMDLINE and in which cases I should use whatever happened to be in data before the function was called. I'll have a look later (gotta run soon) but basically, the reason I did that logic change is that in some specific circumstances and firmware version, I end up writing the user-specified command line in the global prior to actually booting the kernel :-) So in that case, I really don't want CONFIG_CMDLINE to take over because there's nothing in the device-tree, the user -did- specify something but not via the device-tree. Now, that's a bit of an oddball scenario but I felt that the logic change was harmless. For those interested in gory details, it's when doing the OPAL takeover on some machines with the version 1 of OPAL firmware. We basically boot under pHyp normally (pSeries hypervisor) and do a magic hcall which relocates the kernel to contiguous physical memory and re-starts it with a flat device-tree. The takeover mechanism didn't provide me with a way for passing a command line in that fdt. So I had to do it from prom_init (still running under pHyp context), change the kernel global before it gets relocated. Cheers, Ben. Here's the definition in the KConfig: http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=arch/arm/Kconfig;h=24626b0419ee97e963e68329a8eb6769360b46ea;hb=HEAD#l1984 Which case do you have CONFIG_CMDLINE defined but not CMDLINE_FORCE? In those cases, do you happen to have CONFIG_CMDLINE_EXTEND or CMDLINE_FROM_BOOTLOADER defined? Thanks much! -Doug --- On Mon, Sep 19, 2011 at 9:55 PM, Grant Likely grant.lik...@secretlab.ca wrote: On Tue, Sep 20, 2011 at 02:50:15PM +1000, Benjamin Herrenschmidt wrote: We used to overwrite with CONFIG_CMDLINE if we found a chosen node but failed to get bootargs out of it or they were empty, unless CONFIG_CMDLINE_FORCE is set. Instead change that to overwrite if data is non empty after the bootargs check. It allows arch code to have other mechanisms to retrieve the command line prior to parsing the device-tree. Note: CONFIG_CMDLINE_FORCE case should ideally be handled elsewhere as it won't work as it-is if the device-tree has no /chosen node Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org CC: devicetree-disc...@lists-ozlabs.org CC: Grant Likely grant.lik...@secretlab.ca Looks okay to me. Acked-by: Grant Likely grant.lik...@secretlab.ca --- drivers/of/fdt.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) v2. Use data instead of cmd_line so it works on archs like mips who don't pass cmd_line to that function to start with, also add a comment explaining the mechanism. (resent with right list address as well while at it) diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index 65200af..323b722 100644 --- a/drivers/of/fdt.c +++ b/drivers/of/fdt.c @@ -681,9 +681,14 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname, if (p != NULL l 0) strlcpy(data, p, min((int)l, COMMAND_LINE_SIZE)); + /* + * CONFIG_CMDLINE is meant to be a default in case nothing else + * managed to set the command line, unless CONFIG_CMDLINE_FORCE + * is set in which case we override whatever was found earlier. + */ #ifdef CONFIG_CMDLINE #ifndef CONFIG_CMDLINE_FORCE - if (p == NULL || l == 0 || (l == 1 (*p) == 0)) + if (!data[0]) #endif strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE); #endif /* CONFIG_CMDLINE */ -- 1.7.4.1 ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 0/3] ppc32/kprobe: Fix a bug for kprobe stwu r1
Tiejun Chen wrote: Changes from V1: * use memcpy simply to withdraw copy_exc_stack * add !(regs-msr MSR_PR)) and WARN_ON(test_thread_flag(TIF_EMULATE_STACK_STORE)); to make sure we're in goot path. * move this migration process inside 'restore' * clear TIF flag atomically Ben, Is this series OK? Thanks Tiejun Tiejun Chen (3): powerpc/kprobe: introduce a new thread flag ppc32/kprobe: complete kprobe and migrate exception frame ppc32/kprobe: don't emulate store when kprobe stwu r1 arch/powerpc/include/asm/thread_info.h |3 ++ arch/powerpc/kernel/entry_32.S | 35 arch/powerpc/lib/sstep.c | 25 +- 3 files changed, 61 insertions(+), 2 deletions(-) Tiejun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Mac address in the DT
Hi, The fdt_fixup_ethernet() is not supported in the older version of u-boot. So how to go about it in u-boot 1.3.0 version. Regards, Smitha Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mac address in the DT
smitha.va...@wipro.com wrote on 2012/01/10 10:37:14: Hi, The fdt_fixup_ethernet() is not supported in the older version of u-boot. So how to go about it in u-boot 1.3.0 version. Upgrade or find out how its done in your older version, I have no idea. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] driver/misc: Add Pulse Width Modulator (PWM) driver for freescale
The PSC913x PWM with the following features:
* 12-bit prescaler for division of clock
* Active-high or active-low configured output
* Interrupts at compare and roll-over
* Programmable pulse width (duty cycle) and interval (period cycle)
A sysfs interface is provided to control the PWM output:
* Set duty cycle and period cycle
echo 1000 /sys/devices/soc.0/e500.2/ff713000.pwm/duty_ns
echo 5000 /sys/devices/soc.0/e500.2/ff713000.pwm/period_ns
* Show duty cycle and period cycle
cat /sys/devices/soc.0/e500.2/ff713000.pwm/duty_ns
cat /sys/devices/soc.0/e500.2/ff713000.pwm/period_ns
Signed-off-by: Chunhe Lan chunhe@freescale.com
---
arch/powerpc/include/asm/fsl_pwm.h | 111 +
drivers/misc/Kconfig | 11 +
drivers/misc/Makefile |1 +
drivers/misc/fsl_pwm.c | 471
4 files changed, 594 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsl_pwm.h
create mode 100644 drivers/misc/fsl_pwm.c
diff --git a/arch/powerpc/include/asm/fsl_pwm.h
b/arch/powerpc/include/asm/fsl_pwm.h
new file mode 100644
index 000..a6d3bf5
--- /dev/null
+++ b/arch/powerpc/include/asm/fsl_pwm.h
@@ -0,0 +1,111 @@
+/*
+ * Freescale PWM Register Definitions
+ *
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * Author: Chunhe Lan chunhe@freescale.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __ARCH_FSL_PWM_H
+#define __ARCH_FSL_PWM_H
+
+#define FSL_PWMCR_STOPEN (1 25)
+#define FSL_PWMCR_DOZEEN (1 24)
+#define FSL_PWMCR_WAITEN (1 23)
+#define FSL_PWMCR_DEBUGEN (1 22)
+#define FSL_PWMCR_BCTR (1 21)
+#define FSL_PWMCR_HCTR (1 20)
+#define FSL_PWMCR_POUTC_HIGHT (0 18)
+#define FSL_PWMCR_POUTC_LOW(1 18)
+#define FSL_PWMCR_CLKSRC (1 16)
+#define FSL_PWMCR_PRESCALER(x) (((x - 1) 0xFFF) 4)
+#define FSL_MAX_PRESCALER 0x0FFF
+#define FSL_PWMCR_SWR (1 3)
+#define FSL_PWMCR_REPEAT_ONE (0 1)
+#define FSL_PWMCR_REPEAT_TWO (1 1)
+#define FSL_PWMCR_REPEAT_FOUR (2 1)
+#define FSL_PWMCR_REPEAT_EIGHT (3 1)
+#define FSL_PWMCR_EN (1 0)
+
+#define FSL_PWMSR_ALL_MASK 0x007F
+#define FSL_PWMSR_FWE_CMP_ROV_MASK 0x0070
+#define FSL_PWMSR_FWE (1 6)
+#define FSL_PWMSR_CMP (1 5)
+#define FSL_PWMSR_ROV (1 4)
+#define FSL_PWMSR_FE (1 3)
+#define FSL_PWMSR_FIFOAV (7 0)
+
+#define FSL_PWMIR (7 0)
+#define FSL_PWMIR_CIE (1 2)
+#define FSL_PWMIR_RIE (1 1)
+#define FSL_PWMIR_FIE (1 0)
+
+#define FSL_PMUXCR1_SPI1_ANT_TCXO_PWM_GPIO (3 0)
+#define FSL_PMUXCR1_ANT_TCXO_PWM_GPIO (1 0)
+#define FSL_PMUXCR2_UART_PWM_GPIO (3 28)
+#define FSL_PMUXCR2_PWM_GPIO (1 28)
+
+#define FSL_DEVDISR2_PWM1 (1 23)
+#define FSL_DEVDISR2_PWM1_EN (0 23)
+#define FSL_DEVDISR2_PWM2 (1 22)
+#define FSL_DEVDISR2_PWM2_EN (0 22)
+
+#define FSL_DEFAULT_IPG_CLK5 /* 500MHz */
+
+struct pwm_reg {
+ u32 pwmcr; /* PWM Control Register */
+ u32 pwmsr; /* PWM Status Register */
+ u32 pwmir; /* PWM Interrupt Register */
+ u32 pwmsar; /* PWM Sample Register */
+ u32 pwmpr; /* PWM Period Register */
+ u32 pwmcnr; /* PWM Counter Register */
+};
+
+struct pwm_device {
+ struct list_head node;
+ struct device dev;
+
+ const char *label;
+ struct clk *clk;
+ int clk_enabled;
+ struct pwm_reg __iomem *regs;
+ int irq;
+
+ unsigned int use_count;
+ unsigned int pwm_id;
+ int duty;
+ int period;
+ int pwmo_invert;
+
[PATCH 1/3] powerpc/85xx: Add clock driver for PWM
Plugs into the generic powerpc clock driver in
arch/powerpc/kernel/clock.c
The following subset of clk_interface is implemented:
clk_get: get clock via name
clk_put: stubbed
clk_enable: enable clock
clk_disable: disable clock
clk_get_rate: get clock rate in Hz
clk_set_rate: NULL
clk_round_rate: NULL
clk_set_parent: NULL
clk_get_parent: NULL
Signed-off-by: Chunhe Lan chunhe@freescale.com
---
arch/powerpc/include/asm/clock.h| 33 +++
arch/powerpc/platforms/85xx/Makefile|1 +
arch/powerpc/platforms/85xx/pwm-clock.c | 161 +++
3 files changed, 195 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/clock.h
create mode 100644 arch/powerpc/platforms/85xx/pwm-clock.c
diff --git a/arch/powerpc/include/asm/clock.h b/arch/powerpc/include/asm/clock.h
new file mode 100644
index 000..98447eb
--- /dev/null
+++ b/arch/powerpc/include/asm/clock.h
@@ -0,0 +1,33 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * Author: Chunhe Lan chunhe@freescale.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+struct clk {
+ struct list_head node;
+ const char *name; /* unique clock name */
+ const char *function; /* function of the clock */
+ struct device *dev; /* device associated with function */
+ unsigned intid:2; /* clock identification */
+ unsigned long rate_hz;
+ struct clk *parent;
+ void(*mode)(struct clk *clk, int status);
+ u16 users;
+};
+
+extern int clk_register(struct clk *clk);
diff --git a/arch/powerpc/platforms/85xx/Makefile
b/arch/powerpc/platforms/85xx/Makefile
index bc5acb9..ba0d0a9 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_P3041_DS)+= p3041_ds.o corenet_ds.o
obj-$(CONFIG_P3060_QDS) += p3060_qds.o corenet_ds.o
obj-$(CONFIG_P4080_DS)+= p4080_ds.o corenet_ds.o
obj-$(CONFIG_P5020_DS)+= p5020_ds.o corenet_ds.o
+obj-$(CONFIG_FSL_PWM) += pwm-clock.o
obj-$(CONFIG_STX_GP3)+= stx_gp3.o
obj-$(CONFIG_TQM85xx)+= tqm85xx.o
obj-$(CONFIG_SBC8560) += sbc8560.o
diff --git a/arch/powerpc/platforms/85xx/pwm-clock.c
b/arch/powerpc/platforms/85xx/pwm-clock.c
new file mode 100644
index 000..bba9872
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/pwm-clock.c
@@ -0,0 +1,161 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * Implements the clk api defined in include/linux/clk.h
+ *
+ * Author: Chunhe Lan chunhe@freescale.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/export.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/list.h
+#include linux/errno.h
+#include linux/err.h
+#include linux/spinlock.h
+#include linux/delay.h
+#include linux/clk.h
+#include linux/of_platform.h
+#include asm/clk_interface.h
+#include asm/clock.h
+
+static LIST_HEAD(clocks);
+static DEFINE_SPINLOCK(clk_lock);
+
+static struct clk pwm_clk = {
+ .name = pwm-clk,
+ .rate_hz= 0,
+ .users = 1,/* always on */
+ .id = 0,
+};
+
+static struct clk *all_clocks[] __initdata = {
+ pwm_clk,
+};
+
+/* clocks cannot be de-registered no refcounting necessary */
+static struct clk *fsl_clk_get(struct device *dev, const char *id)
+{
+ struct clk *clk;
+
+ list_for_each_entry(clk, clocks, node) {
+ if (strcmp(id, clk-name) == 0)
+ return clk;
+ }
+
+ return
[PATCH 3/3] powerpc/fsl: Document Pulse Width Modulator controller device tree binding
This document is created for freescale PWM node in dts file. In addition,
it explicates the properties and gives example about PWM node.
Signed-off-by: Chunhe Lan chunhe@freescale.com
---
.../devicetree/bindings/powerpc/fsl/pwm.txt| 27
1 files changed, 27 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/pwm.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pwm.txt
b/Documentation/devicetree/bindings/powerpc/fsl/pwm.txt
new file mode 100644
index 000..92d68e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/pwm.txt
@@ -0,0 +1,27 @@
+=
+Freescale Pulse Width Modulator Controller Node
+Copyright (C) 2012 Freescale Semiconductor Inc.
+=
+
+Properties:
+
+- name : Should be pwm.
+- compatible : Should contain fsl,psc9131-pwm.
+- cell-index : The cell index is the pwm controller serial number,
+ 0 = PWM1, 1 = PWM2, and so on.
+- #address-cells : Should be one.
+- #size-cells : Should be zero.
+- reg : Offset and length of the register set for the device.
+- interrupts : interrupt mapping for PWM IRQ
+
+Example:
+
+ pwm@13000 {
+ cell-index = 1;
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,psc9131-pwm;
+ reg = 0x13000 0x1000;
+ interrupts = 44 2 0 0;
+ interrupt-parent = mpic;
+ };
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: OpenPIC warnings on P1022RDK AMP configuration
Change kernel configuration as per following to fix this warning. Disable Kernel Options - Support for enabling/disabling CPUs Disable Kernel Options - Distribute interrupts on all CPUs by default Regards, Farrukh Arshad From: Arshad, Farrukh Sent: Friday, December 23, 2011 11:18 AM To: linuxppc-dev@lists.ozlabs.org Subject: OpenPIC warnings on P1022RDK AMP configuration Greetings All I am running dual linux on P1022RDK in AMP configuration. My memory partitioning is as below - Core | Base Address |Size | --|---|-| Core 0 (MEL RT Kernel)| 0x, | 0x0C00, - 192 (MB) | Core 1 (LTIB Kernel) |0x0C00,| 0x1000, - 256 (MB) | MCAPI - Shared Mem| 0x1C00, | 0x0400, - 64 (MB) | - My kernel command lines are for both cores setenv core0bootargs root=/dev/mmcblk0p3 rootdelay=5 rw mem=192M setenv core1bootargs root=/dev/nfs nfsroot=serverip:/rootfs ip=dhcp mem=256M I have also partitioned my hardware among both cores and supplied appropriate protected-sources in mpic node of both DTS files. The problem is, I receive following warning continuously only on Core 0 console, but Core 1 is running smooth. In following warnings source irqs are mostly which I have assigned to Core 1, but they are present in Core 0 mpic node protected-sources list, then why I am getting these messages. [6.219204] __ratelimit: 5796 callbacks suppressed [6.223996] OpenPIC : Got protected source 30 ! [7.005809] OpenPIC : Got protected source 30 ! [8.005906] OpenPIC : Got protected source 30 ! [8.433053] OpenPIC : Got protected source 29 ! [8.437942] OpenPIC : Got protected source 30 ! [8.443101] OpenPIC : Got protected source 30 ! [8.448428] OpenPIC : Got protected source 30 ! Any thoughts ? Best Regards Farrukh Arshad Sr. Software Development Engineer Mentor Graphics Pakistan Ph: +92 - 423 - 609 - 92 - 09 Cell: +92 - 303 - 444 - 77 - 05 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Add P1024rdb dts support
On 01/09/2012 09:45 PM, Tang Yuantian-B29983 wrote: On 01/09/2012 02:37 AM, b29...@freescale.com wrote: +/include/ p1024rdb.dtsi +/include/ fsl/p1020si-post.dtsi Is p1024 100% software-compatible with p1020? They have different manuals... -Scott P1020rdb has vitesse-7385 switch. I'm talking about the SoC, not the board. fsl/p1020si-post.dtsi can be used for both boards. What are you basing this on? Has someone looked over both manuals in detail and concluded that every device described is 100% compatible? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: OpenPIC warnings on P1022RDK AMP configuration
On 01/10/2012 02:43 AM, Arshad, Farrukh wrote: Change kernel configuration as per following to fix this warning. Disable Kernel Options - Support for enabling/disabling CPUs Disable Kernel Options - Distribute interrupts on all CPUs by default Regards, Farrukh Arshad *From:*Arshad, Farrukh *Sent:* Friday, December 23, 2011 11:18 AM *To:* linuxppc-dev@lists.ozlabs.org *Subject:* OpenPIC warnings on P1022RDK AMP configuration Greetings All I am running dual linux on P1022RDK in AMP configuration. My memory partitioning is as below - Core | Base Address |Size | --|---|-| Core 0 (MEL RT Kernel)| 0x, | 0x0C00, - 192 (MB) | Core 1 (LTIB Kernel) |0x0C00,| 0x1000, - 256 (MB) | MCAPI - Shared Mem| 0x1C00, | 0x0400, - 64 (MB) | - My kernel command lines are for both cores setenv core0bootargs root=/dev/mmcblk0p3 rootdelay=5 rw mem=192M setenv core1bootargs root=/dev/nfs nfsroot=serverip:/rootfs ip=dhcp mem=256M I have also partitioned my hardware among both cores and supplied appropriate “protected-sources” in mpic node of both DTS files. The problem is, I receive following warning continuously only on Core 0 console, but Core 1 is running smooth. In following warnings source irqs are mostly which I have assigned to Core 1, but they are present in Core 0 mpic node “protected-sources” list, then why I am getting these messages. [6.219204] __ratelimit: 5796 callbacks suppressed [6.223996] OpenPIC : Got protected source 30 ! [7.005809] OpenPIC : Got protected source 30 ! [8.005906] OpenPIC : Got protected source 30 ! [8.433053] OpenPIC : Got protected source 29 ! [8.437942] OpenPIC : Got protected source 30 ! [8.443101] OpenPIC : Got protected source 30 ! [8.448428] OpenPIC : Got protected source 30 ! Any thoughts ? Does each dtb have the correct CPU number, both from the command line boot cpu flag and in the CPU node? Do both device trees have pic-no-reset in the mpic node? If neither of those are the issue, start dumping the relevant MPIC interrupt destination registers, and tracethe code where they're supposed to be set up. Also make sure that no interrupts are enabled when Linux receives control from U-Boot. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mac address in the DT
Dear smitha.va...@wipro.com, In message 40631e9a2581f14ba60888c87a76a1fe01d...@hyd-mkd-mbx4.wipro.com you wrote: The fdt_fixup_ethernet() is not supported in the older version of u-boot. So how to go about it in u-boot 1.3.0 version. U-Boot v1.3.0 is more than 4 years old. Update, or restrict yourself to using 4 years old Linux kernel versions as well, like v2.6.23 or so :-( Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Everyting looks interesting until you do it. Then you find it's just another job. - Terry Pratchett, _Moving Pictures_ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 14/16] KVM: PPC: booke: category E.HV (GS-mode) support
On 01/09/2012 09:11 PM, Alexander Graf wrote: On 10.01.2012, at 01:51, Scott Wood wrote: On 01/09/2012 11:46 AM, Alexander Graf wrote: On 21.12.2011, at 02:34, Scott Wood wrote: + /* For debugging, encode the failing instruction and + * report it to userspace. */ + run-hw.hardware_exit_reason = ~0ULL 32; + run-hw.hardware_exit_reason |= vcpu-arch.last_inst; I'm fairly sure you want to fix this :) Likewise, that's what booke.c already does. What should it do instead? This is what book3s does: case EMULATE_FAIL: printk(KERN_CRIT %s: emulation at %lx failed (%08x)\n, __func__, kvmppc_get_pc(vcpu), kvmppc_get_last_inst(vcpu)); kvmppc_core_queue_program(vcpu, flags); r = RESUME_GUEST; which also doesn't throttle the printk, but I think injecting a program fault into the guest is the most sensible thing to do if we don't know what the instruction is supposed to do. Best case we get an oops inside the guest telling us what broke :). Ah, yes, it should send a program check. Ah, so that's what you want to use regs for. So is having a pt_regs struct that only contains useful register values in half its fields any useful here? Or could we keep control of the registers ourselves, enabling us to maybe one day optimize things more. I think it contains enough to be useful for debugging code such as sysrq and tracers, and as noted in the comment we could copy the rest if we care enough. MSR might be worth copying. It will eventually be used for machine checks as well, which I'd like to hand reasonable register state to, at least for GPRs, LR, and PC. If there's a good enough performance reason, we could just copy everything over for machine checks and pass NULL to do_IRQ (I think it can take this -- a dummy regs struct if not), but it seems premature at the moment unless the switch already causes measured performance loss (cache utilization?). I'm definitely not concerned about performance, but complexity and uniqueness. With the pt_regs struct, we have a bunch of fields in the vcpu that are there, but unused. I find that situation pretty confusing. I removed the registers from the vcpu, that are to be used in regs instead. There are a few fields in regs that are not valid, though it is explicitly pointed out via a comment. So yes, I would definitely prefer to copy registers during MC and keep the registers where they are today - unless there are SPRs for them of course. Imagine we'd one day want to share GPRs with user space through the kvm_run structure (see the s390 patches on the ML for this). I really wouldn't want to make pt_regs part of our userspace ABI. Neither would I. If that's something that's reasonably likely to happen, I guess that's a good enough reason to avoid this. We could always add later a debug option to copy regs even on normal interrupts, if needed. We probably should defer the check until after we've disabled interrupts, similar to signals -- even if we didn't exit for an interrupt, we could have received one after enabling them. Yup. I just don't think you can call resched() with interrupts disabled, so a bit cleverness is probably required here. I think it is actually allowed, but interrupts will be enabled on return. We'll need to repeat prepare_to_enter if we do schedule. Since we already need special handling for that, we might as well add a local_irq_enable() once we know we are going to schedule, just in case. diff --git a/arch/powerpc/kvm/booke.h b/arch/powerpc/kvm/booke.h index 05d1d99..d53bcf2 100644 --- a/arch/powerpc/kvm/booke.h +++ b/arch/powerpc/kvm/booke.h @@ -48,7 +48,20 @@ #define BOOKE_IRQPRIO_PERFORMANCE_MONITOR 19 /* Internal pseudo-irqprio for level triggered externals */ #define BOOKE_IRQPRIO_EXTERNAL_LEVEL 20 -#define BOOKE_IRQPRIO_MAX 20 +#define BOOKE_IRQPRIO_DBELL 21 +#define BOOKE_IRQPRIO_DBELL_CRIT 22 +#define BOOKE_IRQPRIO_MAX 23 So was MAX wrong before or is it too big now? MAX is just a marker for how many IRQPRIOs we have, not any sort of external limit. This patch adds new IRQPRIOs, so MAX goes up. The actual limit is the number of bits in a long. Yes, and before the highest value was 20 with MAX being 20, now the highest value is 22 with MAX being 23. Either MAX == highest number or MAX == highest number + 1, but you're changing the semantics of MAX here. Maybe it was wrong before, I don't know, hence I'm asking :). Oh, didn't notice that. Actually, it looks like the two places that reference BOOKE_IRQPRIO_MAX don't agree on what they're expecting. book3s uses one greater than the highest irqprio, so I guess we should resolve it that way (even though I'd normally expect that to be phrased num rather than max) -- as a separate patch, of course. -Scott
Re: [RFC PATCH 16/16] KVM: PPC: e500mc support
On 01/10/2012 02:37 AM, Avi Kivity wrote: On 01/09/2012 09:29 PM, Scott Wood wrote: Best to include their signoffs, if possible. These patches are based in part on a bunch of different patches from these people (for which I did receive signoffs). I was reluctant to put their signoff directly on the new patches, since I didn't want to make it look like they had submitted the patch in anything resembling its current form. I wanted to give them credit for what they did, but not blame for what I did with their code. Signoffs are for assigning neither credit nor blame, but for attributing authorship and affirming that a contributor has the right to contribute code or pass it along. That's its formal purpose, but some people draw other conclusions from it regardless. From Documentation/SubmittingPatches: Rule (b) allows you to adjust the code, but then it is very impolite to change one submitter's code and make him endorse your bugs. Please read the DCO at https://lwn.net/Articles/437739/. I've read it. My signoff here qualifies based on (a) and (b). (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or Note or in part. The contributions in this patch were all produced by Freescale employees on a work for hire basis (other than the extent to which the code is derived from code already in the Linux kernel, which is covered by (b)), and I am authorized to submit this work on Freescale's behalf for inclusion into the Linux kernel under GPLv2. I'm not trying to be difficult, just to avoid looking like it was a patch passed more-or-less as-is from person to person. When I resubmit, I can put the sign-offs in with [scottw...@freescale.com: significant rework] after them, or list them separately as part of the based on... paragraph. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 14/16] KVM: PPC: booke: category E.HV (GS-mode) support
On 10.01.2012, at 23:03, Scott Wood wrote: On 01/09/2012 09:11 PM, Alexander Graf wrote: On 10.01.2012, at 01:51, Scott Wood wrote: On 01/09/2012 11:46 AM, Alexander Graf wrote: On 21.12.2011, at 02:34, Scott Wood wrote: + /* For debugging, encode the failing instruction and + * report it to userspace. */ + run-hw.hardware_exit_reason = ~0ULL 32; + run-hw.hardware_exit_reason |= vcpu-arch.last_inst; I'm fairly sure you want to fix this :) Likewise, that's what booke.c already does. What should it do instead? This is what book3s does: case EMULATE_FAIL: printk(KERN_CRIT %s: emulation at %lx failed (%08x)\n, __func__, kvmppc_get_pc(vcpu), kvmppc_get_last_inst(vcpu)); kvmppc_core_queue_program(vcpu, flags); r = RESUME_GUEST; which also doesn't throttle the printk, but I think injecting a program fault into the guest is the most sensible thing to do if we don't know what the instruction is supposed to do. Best case we get an oops inside the guest telling us what broke :). Ah, yes, it should send a program check. Ah, so that's what you want to use regs for. So is having a pt_regs struct that only contains useful register values in half its fields any useful here? Or could we keep control of the registers ourselves, enabling us to maybe one day optimize things more. I think it contains enough to be useful for debugging code such as sysrq and tracers, and as noted in the comment we could copy the rest if we care enough. MSR might be worth copying. It will eventually be used for machine checks as well, which I'd like to hand reasonable register state to, at least for GPRs, LR, and PC. If there's a good enough performance reason, we could just copy everything over for machine checks and pass NULL to do_IRQ (I think it can take this -- a dummy regs struct if not), but it seems premature at the moment unless the switch already causes measured performance loss (cache utilization?). I'm definitely not concerned about performance, but complexity and uniqueness. With the pt_regs struct, we have a bunch of fields in the vcpu that are there, but unused. I find that situation pretty confusing. I removed the registers from the vcpu, that are to be used in regs instead. There are a few fields in regs that are not valid, though it is explicitly pointed out via a comment. Yes, and if there was real technical reason to do it this way I'd agree. But there isn't. So yes, I would definitely prefer to copy registers during MC and keep the registers where they are today - unless there are SPRs for them of course. Imagine we'd one day want to share GPRs with user space through the kvm_run structure (see the s390 patches on the ML for this). I really wouldn't want to make pt_regs part of our userspace ABI. Neither would I. If that's something that's reasonably likely to happen, I guess that's a good enough reason to avoid this. We could always add later a debug option to copy regs even on normal interrupts, if needed. Yup. I don't want to walk in the wrong direction basically. The overhead of copying a couple fields to the stack on machine checks doesn't sound too bad compared to the flexibility we maintain by keeping fields under our control. Another imaginary case. I experimented with putting the GPRs into the PACA back in the day. I don't remember why anymore, but it was for some speedup of something. That wouldn't be possible if we mandate everyone to use pt_regs. We probably should defer the check until after we've disabled interrupts, similar to signals -- even if we didn't exit for an interrupt, we could have received one after enabling them. Yup. I just don't think you can call resched() with interrupts disabled, so a bit cleverness is probably required here. I think it is actually allowed, but interrupts will be enabled on return. We'll need to repeat prepare_to_enter if we do schedule. Since we already need special handling for that, we might as well add a local_irq_enable() once we know we are going to schedule, just in case. Yup :). And then check again. diff --git a/arch/powerpc/kvm/booke.h b/arch/powerpc/kvm/booke.h index 05d1d99..d53bcf2 100644 --- a/arch/powerpc/kvm/booke.h +++ b/arch/powerpc/kvm/booke.h @@ -48,7 +48,20 @@ #define BOOKE_IRQPRIO_PERFORMANCE_MONITOR 19 /* Internal pseudo-irqprio for level triggered externals */ #define BOOKE_IRQPRIO_EXTERNAL_LEVEL 20 -#define BOOKE_IRQPRIO_MAX 20 +#define BOOKE_IRQPRIO_DBELL 21 +#define BOOKE_IRQPRIO_DBELL_CRIT 22 +#define BOOKE_IRQPRIO_MAX 23 So was MAX wrong before or is it too big now? MAX is just a marker for how many IRQPRIOs we have, not any sort of external limit. This patch adds new IRQPRIOs, so MAX goes up. The actual limit is the number of bits in a long. Yes,
Re: [PATCH v2 0/3] ppc32/kprobe: Fix a bug for kprobe stwu r1
On Tue, 2012-01-10 at 17:15 +0800, tiejun.chen wrote: Tiejun Chen wrote: Changes from V1: * use memcpy simply to withdraw copy_exc_stack * add !(regs-msr MSR_PR)) and WARN_ON(test_thread_flag(TIF_EMULATE_STACK_STORE)); to make sure we're in goot path. * move this migration process inside 'restore' * clear TIF flag atomically Ben, Is this series OK? Not completely sorry. I was about to send you some comments a couple of weeks ago then had to leave urgently and forgot about it, then started rewriting your code and didn't finish :-) I'll give you some more feedback asap, sorry about that. It's getting there but there's a couple of things I'd like to see done a bit differently. Cheers, Ben. Thanks Tiejun Tiejun Chen (3): powerpc/kprobe: introduce a new thread flag ppc32/kprobe: complete kprobe and migrate exception frame ppc32/kprobe: don't emulate store when kprobe stwu r1 arch/powerpc/include/asm/thread_info.h |3 ++ arch/powerpc/kernel/entry_32.S | 35 arch/powerpc/lib/sstep.c | 25 +- 3 files changed, 61 insertions(+), 2 deletions(-) Tiejun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] cpuidle: Default y for pseries
We just replaced the pseries platform idle loops with a cpuidle backend, however that means that you won't get any power saving and won't return any unused idle time to the hypervisor unless cpuidle is enabled. Thus is should default to y when pseries is enabled. I prefer that to a select so we can still make it modular if we want to. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- Linus, do you want to just pick that up or should I put it into powerpc.git and ask you to pull ? I will have 2 or 3 other fixes there later today, but I wanted to make sure you were ok with the approach with this specific one. diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig index 7dbc4a8..62ca70d 100644 --- a/drivers/cpuidle/Kconfig +++ b/drivers/cpuidle/Kconfig @@ -1,7 +1,8 @@ config CPU_IDLE bool CPU idle PM support - default ACPI + default y if ACPI + default y if PPC_PSERIES help CPU idle is a generic framework for supporting software-controlled idle processor power management. It includes modular cross-platform ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/85xx: Add P1024rdb dts support
P1020rdb has vitesse-7385 switch. I'm talking about the SoC, not the board. fsl/p1020si-post.dtsi can be used for both boards. What are you basing this on? Has someone looked over both manuals in detail and concluded that every device described is 100% compatible? I ported this from the dts in kernel 2.6.35. I found they are 100% compatible from dts point of view. Regards, Yuantian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Mac address in the DT
Hi, I am using 2.6.21 linux kernel with this bootloader. The ethernet driver in the kernel reads the mac address from the .dtb file. Regards, Smitha Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cpuidle: Default y for pseries
On Tue, Jan 10, 2012 at 5:05 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Linus, do you want to just pick that up or should I put it into powerpc.git and ask you to pull ? I will have 2 or 3 other fixes there later today, but I wanted to make sure you were ok with the approach with this specific one. It doesn't seem to be all that different from the default y if ACPI case, so I guess it works ok. That said, I wonder if the right approach wouldn't be default y if SUPPORT_CPU_IDLE or something along those lines. And then both ACPI and PPC_PSERIES could just select that instead. Because I do hate having random board-level knowledge in something like this. I dunno. Linus ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cpuidle: Default y for pseries
On Tue, 2012-01-10 at 22:08 -0800, Linus Torvalds wrote: On Tue, Jan 10, 2012 at 5:05 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Linus, do you want to just pick that up or should I put it into powerpc.git and ask you to pull ? I will have 2 or 3 other fixes there later today, but I wanted to make sure you were ok with the approach with this specific one. It doesn't seem to be all that different from the default y if ACPI case, so I guess it works ok. It works for my case, that's tested, but ... That said, I wonder if the right approach wouldn't be default y if SUPPORT_CPU_IDLE or something along those lines. And then both ACPI and PPC_PSERIES could just select that instead. Because I do hate having random board-level knowledge in something like this. I dunno. I tend to agree, I wasn't too keen on touching ACPI related stuff I suppose it shouldn't be hard :-) Btw, what about the change: - default ACPI + default y if ACPI (To be honest I'm not sure what the first form does in details). Oh, also, I just see that in drivers/acpi/Kconfig: config ACPI_PROCESSOR tristate Processor select THERMAL select CPU_IDLE default y Hrm... maybe I should just do the same in pseries and remove both the default statements above, what do you think ? On pSeries I'm keen to build that in rather than make it a module too because you get no idle handling until it loads which can be problematic. Built-in, it seems to be quite early in the link order (if we can still trust that nowadays ...). Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: OpenPIC warnings on P1022RDK AMP configuration
Does each dtb have the correct CPU number, both from the command line boot cpu flag and in the CPU node? Yes both CPUs have the correct CPU numbers and also both DTBs are build with their respective -b flag. Do both device trees have pic-no-reset in the mpic node? Yes, both have pic-no-reset mode. If neither of those are the issue, start dumping the relevant MPIC interrupt destination registers, and tracethe code where they're supposed to be set up. Also make sure that no interrupts are enabled when Linux receives control from U-Boot. Yes, interrupts are disabled when Linux receives control from U-Boot. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] dmaengine: async_xor, fix zero address issue when xor highmem page
Hello Dan Williams,
Do you have any comment about this patch?
Thanks,
Forrest
-Original Message-
From: Shi Xuelin-B29237
Sent: 2011年12月27日 14:31
To: vinod.k...@intel.com; dan.j.willi...@intel.com;
linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; Li Yang-R58472
Cc: Shi Xuelin-B29237
Subject: [PATCH] dmaengine: async_xor, fix zero address issue when xor highmem
page
From: Forrest shi b29...@freescale.com
we may do_sync_xor high mem pages, in this case, page_address will
return zero address which cause a failure.
this patch uses kmap_atomic before xor the pages and kunmap_atomic
after it.
Signed-off-by: b29...@freescale.com xuelin@freescale.com
---
crypto/async_tx/async_xor.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c index
bc28337..5b416d1 100644
--- a/crypto/async_tx/async_xor.c
+++ b/crypto/async_tx/async_xor.c
@@ -26,6 +26,7 @@
#include linux/kernel.h
#include linux/interrupt.h
#include linux/mm.h
+#include linux/highmem.h
#include linux/dma-mapping.h
#include linux/raid/xor.h
#include linux/async_tx.h
@@ -126,7 +127,7 @@ do_sync_xor(struct page *dest, struct page **src_list,
unsigned int offset,
int src_cnt, size_t len, struct async_submit_ctl *submit) {
int i;
- int xor_src_cnt = 0;
+ int xor_src_cnt = 0, kmap_cnt=0;
int src_off = 0;
void *dest_buf;
void **srcs;
@@ -138,11 +139,13 @@ do_sync_xor(struct page *dest, struct page **src_list,
unsigned int offset,
/* convert to buffer pointers */
for (i = 0; i src_cnt; i++)
- if (src_list[i])
- srcs[xor_src_cnt++] = page_address(src_list[i]) +
offset;
+ if (src_list[i]) {
+ srcs[xor_src_cnt++] = kmap_atomic(src_list[i],
KM_USER1) + offset;
+ }
+ kmap_cnt = xor_src_cnt;
src_cnt = xor_src_cnt;
/* set destination address */
- dest_buf = page_address(dest) + offset;
+ dest_buf = kmap_atomic(dest, KM_USER0) + offset;
if (submit-flags ASYNC_TX_XOR_ZERO_DST)
memset(dest_buf, 0, len);
@@ -157,6 +160,11 @@ do_sync_xor(struct page *dest, struct page **src_list,
unsigned int offset,
src_off += xor_src_cnt;
}
+ kunmap_atomic(dest_buf, KM_USER0);
+ for (i = 0; i kmap_cnt; i++)
+ if (src_list[i])
+ kunmap_atomic(srcs[i], KM_USER1);
+
async_tx_sync_epilog(submit);
}
--
1.7.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] fsldma: fix performance degradation by optimizing spinlock use.
Hello Iris, As we discussed in the previous patch, I add one smp_mb() in fsl_tx_status. In my testing with iozone, this smp_mb() could cause 1%~2% performance degradation. Anyway it is acceptable for me. Do you have any other comments? Thanks, Forrest -Original Message- From: Shi Xuelin-B29237 Sent: 2011年12月26日 14:01 To: i...@ovro.caltech.edu; vinod.k...@intel.com; dan.j.willi...@intel.com; linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org Cc: Shi Xuelin-B29237 Subject: [PATCH] fsldma: fix performance degradation by optimizing spinlock use. From: Forrest shi b29...@freescale.com dma status check function fsl_tx_status is heavily called in a tight loop and the desc lock in fsl_tx_status contended by the dma status update function. this caused the dma performance degrades much. this patch releases the lock in the fsl_tx_status function, and introduce the smp_mb() to avoid possible memory inconsistency. Signed-off-by: Forrest Shi xuelin@freescale.com --- drivers/dma/fsldma.c |6 +- 1 files changed, 1 insertions(+), 5 deletions(-) diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index 8a78154..008fb5e 100644 --- a/drivers/dma/fsldma.c +++ b/drivers/dma/fsldma.c @@ -986,15 +986,11 @@ static enum dma_status fsl_tx_status(struct dma_chan *dchan, struct fsldma_chan *chan = to_fsl_chan(dchan); dma_cookie_t last_complete; dma_cookie_t last_used; - unsigned long flags; - - spin_lock_irqsave(chan-desc_lock, flags); last_complete = chan-completed_cookie; + smp_mb(); last_used = dchan-cookie; - spin_unlock_irqrestore(chan-desc_lock, flags); - dma_set_tx_state(txstate, last_complete, last_used, 0); return dma_async_is_complete(cookie, last_complete, last_used); } -- 1.7.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
