Re: [PATCH 1/5] powerpc: Remove bootmem allocator
Hello Anton, On 09/17/2014 07:15 AM, Anton Blanchard wrote: At the moment we transition from the memblock alloctor to the bootmem allocator. Gitting rid of the bootmem allocator removes a bunch of complicated code (most of which I owe the dubious honour of being responsible for writing). Signed-off-by: Anton Blanchard an...@samba.org Tested-by: Emil Medve emilian.me...@freescale.com --- arch/powerpc/Kconfig | 1 + arch/powerpc/include/asm/setup.h | 3 +- arch/powerpc/kernel/setup_32.c | 5 +- arch/powerpc/kernel/setup_64.c | 3 +- arch/powerpc/mm/init_32.c| 9 -- arch/powerpc/mm/mem.c| 62 +-- arch/powerpc/mm/numa.c | 224 ++- arch/powerpc/mm/pgtable_32.c | 3 +- arch/powerpc/mm/pgtable_64.c | 6 +- 9 files changed, 43 insertions(+), 273 deletions(-) Any idea on how to move these patches forward? Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
Add BPF extension SKF_AD_PKTTYPE to ppc JIT to load
skb-pkt_type field.
Before:
[ 88.262622] test_bpf: #11 LD_IND_NET 86 97 99 PASS
[ 88.265740] test_bpf: #12 LD_PKTTYPE 109 107 PASS
After:
[ 80.605964] test_bpf: #11 LD_IND_NET 44 40 39 PASS
[ 80.607370] test_bpf: #12 LD_PKTTYPE 9 9 PASS
CC: Alexei Starovoitovalexei.starovoi...@gmail.com
CC: Michael Ellermanm...@ellerman.id.au
Cc: Matt Evans m...@ozlabs.org
Signed-off-by: Denis Kirjanov k...@linux-powerpc.org
v2: Added test rusults
---
arch/powerpc/include/asm/ppc-opcode.h | 1 +
arch/powerpc/net/bpf_jit.h| 7 +++
arch/powerpc/net/bpf_jit_comp.c | 5 +
3 files changed, 13 insertions(+)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h
b/arch/powerpc/include/asm/ppc-opcode.h
index 6f85362..1a52877 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -204,6 +204,7 @@
#define PPC_INST_ERATSX_DOT0x7c000127
/* Misc instructions for BPF compiler */
+#define PPC_INST_LBZ 0x8800
#define PPC_INST_LD0xe800
#define PPC_INST_LHZ 0xa000
#define PPC_INST_LHBRX 0x7c00062c
diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
index 9aee27c..c406aa9 100644
--- a/arch/powerpc/net/bpf_jit.h
+++ b/arch/powerpc/net/bpf_jit.h
@@ -87,6 +87,9 @@ DECLARE_LOAD_FUNC(sk_load_byte_msh);
#define PPC_STD(r, base, i)EMIT(PPC_INST_STD | ___PPC_RS(r) |\
___PPC_RA(base) | ((i) 0xfffc))
+
+#define PPC_LBZ(r, base, i)EMIT(PPC_INST_LBZ | ___PPC_RT(r) |\
+___PPC_RA(base) | IMM_L(i))
#define PPC_LD(r, base, i) EMIT(PPC_INST_LD | ___PPC_RT(r) | \
___PPC_RA(base) | IMM_L(i))
#define PPC_LWZ(r, base, i)EMIT(PPC_INST_LWZ | ___PPC_RT(r) |\
@@ -96,6 +99,10 @@ DECLARE_LOAD_FUNC(sk_load_byte_msh);
#define PPC_LHBRX(r, base, b) EMIT(PPC_INST_LHBRX | ___PPC_RT(r) | \
___PPC_RA(base) | ___PPC_RB(b))
/* Convenience helpers for the above with 'far' offsets: */
+#define PPC_LBZ_OFFS(r, base, i) do { if ((i) 32768) PPC_LBZ(r, base, i); \
+ else { PPC_ADDIS(r, base, IMM_HA(i));\
+ PPC_LBZ(r, r, IMM_L(i)); } } while(0)
+
#define PPC_LD_OFFS(r, base, i) do { if ((i) 32768) PPC_LD(r, base, i); \
else { PPC_ADDIS(r, base, IMM_HA(i));\
PPC_LD(r, r, IMM_L(i)); } } while(0)
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index cbae2df..d110e28 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -407,6 +407,11 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32
*image,
PPC_LHZ_OFFS(r_A, r_skb, offsetof(struct sk_buff,
queue_mapping));
break;
+ case BPF_ANC | SKF_AD_PKTTYPE:
+ PPC_LBZ_OFFS(r_A, r_skb, PKT_TYPE_OFFSET());
+ PPC_ANDI(r_A, r_A, PKT_TYPE_MAX);
+ PPC_SRWI(r_A, r_A, 5);
+ break;
case BPF_ANC | SKF_AD_CPU:
#ifdef CONFIG_SMP
/*
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: FSL MSI Mapping
On Thu, Oct 30, 2014 at 02:51:57PM +1100, Michael Ellerman wrote: On Tue, 2014-10-28 at 18:06 +0100, Johannes Thumshirn wrote: Hi, I got notified about your patch to support multiple MSI Vectors on Freescale PowerPC platforms. Is there any reason why it wasn't applied until now? I couldn't find anything about it in the list archives. I think it would be a real benefit for all to have multiple MSI vecotrs on PowerPCs. Why would you not use MSI-X ? Simply because our hardware only supports MSI. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 1/3] QE: move qe code from arch/powerpc to drivers/soc
LS1 is arm cpu and it has qe ip block.
move qe code from platform directory to public directory.
QE is an IP block integrates several comunications peripheral
controllers. It can implement a variety of applications, such
as uart, usb and tdm and so on.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
Changes for v2:
- move code to driver/soc
Changes for v3:
- change drivers/soc/qe to drivers/soc/fsl-qe
arch/powerpc/Kconfig | 2 -
arch/powerpc/platforms/83xx/km83xx.c | 4 +-
arch/powerpc/platforms/83xx/misc.c | 2 +-
arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 +-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 +-
arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 +-
arch/powerpc/platforms/85xx/common.c | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 +-
arch/powerpc/platforms/85xx/twr_p102x.c| 4 +-
arch/powerpc/platforms/Kconfig | 19 -
arch/powerpc/sysdev/Makefile | 1 -
arch/powerpc/sysdev/qe_lib/Kconfig | 27 -
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
drivers/net/ethernet/freescale/ucc_geth.c | 8 ++--
drivers/net/ethernet/freescale/ucc_geth.h | 8 ++--
drivers/soc/Kconfig| 2 +
drivers/soc/Makefile | 1 +
drivers/soc/fsl-qe/Kconfig | 45 ++
.../sysdev/qe_lib = drivers/soc/fsl-qe}/Makefile | 0
.../sysdev/qe_lib = drivers/soc/fsl-qe}/gpio.c| 2 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/qe.c | 4 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/qe_ic.c | 2 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/qe_ic.h | 2 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/qe_io.c | 2 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/ucc.c | 6 +--
.../qe_lib = drivers/soc/fsl-qe}/ucc_fast.c | 8 ++--
.../qe_lib = drivers/soc/fsl-qe}/ucc_slow.c | 8 ++--
.../sysdev/qe_lib = drivers/soc/fsl-qe}/usb.c | 4 +-
drivers/spi/spi-fsl-cpm.c | 2 +-
drivers/tty/serial/ucc_uart.c | 2 +-
drivers/usb/gadget/fsl_qe_udc.c| 2 +-
drivers/usb/host/fhci-hcd.c| 2 +-
drivers/usb/host/fhci-hub.c| 2 +-
drivers/usb/host/fhci-sched.c | 2 +-
drivers/usb/host/fhci.h| 4 +-
.../include/asm = include/linux/fsl}/immap_qe.h | 0
.../powerpc/include/asm = include/linux/fsl}/qe.h | 2 +-
.../include/asm = include/linux/fsl}/qe_ic.h | 0
.../include/asm = include/linux/fsl}/ucc.h| 4 +-
.../include/asm = include/linux/fsl}/ucc_fast.h | 6 +--
.../include/asm = include/linux/fsl}/ucc_slow.h | 6 +--
44 files changed, 112 insertions(+), 113 deletions(-)
delete mode 100644 arch/powerpc/sysdev/qe_lib/Kconfig
create mode 100644 drivers/soc/fsl-qe/Kconfig
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/Makefile (100%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/gpio.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/qe.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/qe_ic.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/qe_ic.h (98%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/qe_io.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/ucc.c (98%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/ucc_fast.c (98%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/ucc_slow.c (98%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/usb.c (96%)
rename {arch/powerpc/include/asm = include/linux/fsl}/immap_qe.h (100%)
rename {arch/powerpc/include/asm = include/linux/fsl}/qe.h (99%)
rename {arch/powerpc/include/asm = include/linux/fsl}/qe_ic.h (100%)
rename {arch/powerpc/include/asm = include/linux/fsl}/ucc.h (96%)
rename {arch/powerpc/include/asm = include/linux/fsl}/ucc_fast.h (98%)
rename {arch/powerpc/include/asm = include/linux/fsl}/ucc_slow.h (99%)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index d003409..007b052 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -1054,8 +1054,6 @@ source drivers/Kconfig
source fs/Kconfig
-source arch/powerpc/sysdev/qe_lib/Kconfig
-
source lib/Kconfig
source arch/powerpc/Kconfig.debug
diff --git a/arch/powerpc/platforms/83xx/km83xx.c
b/arch/powerpc/platforms/83xx/km83xx.c
index bf4c447..584d8cc 100644
--- a/arch/powerpc/platforms/83xx/km83xx.c
+++ b/arch/powerpc/platforms/83xx/km83xx.c
@@ -37,8 +37,8 @@
#include asm/udbg.h
#include sysdev/fsl_soc.h
#include sysdev/fsl_pci.h
[PATCH v3 2/3] qe_common: add qe common functions into qe_common.c
qe need to call some common functions,
add a new file drivers/soc/fsl-qe/qe_common.c
for them.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
drivers/soc/fsl-qe/Makefile| 2 +-
drivers/soc/fsl-qe/qe_common.c | 185 +
include/linux/fsl/qe.h | 52 ++--
3 files changed, 230 insertions(+), 9 deletions(-)
create mode 100644 drivers/soc/fsl-qe/qe_common.c
diff --git a/drivers/soc/fsl-qe/Makefile b/drivers/soc/fsl-qe/Makefile
index f1855c1..77f6fd9 100644
--- a/drivers/soc/fsl-qe/Makefile
+++ b/drivers/soc/fsl-qe/Makefile
@@ -1,7 +1,7 @@
#
# Makefile for the linux ppc-specific parts of QE
#
-obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_ic.o qe_io.o
+obj-$(CONFIG_QUICC_ENGINE)+= qe.o qe_ic.o qe_io.o qe_common.o
obj-$(CONFIG_UCC) += ucc.o
obj-$(CONFIG_UCC_SLOW) += ucc_slow.o
diff --git a/drivers/soc/fsl-qe/qe_common.c b/drivers/soc/fsl-qe/qe_common.c
new file mode 100644
index 000..c82ddcc
--- /dev/null
+++ b/drivers/soc/fsl-qe/qe_common.c
@@ -0,0 +1,185 @@
+/*
+ * Common QE code
+ *
+ * Author: Scott Wood scottw...@freescale.com
+ *
+ * Copyright 2007-2008,2010 Freescale Semiconductor, Inc.
+ *
+ * Some parts derived from commproc.c/cpm2_common.c, which is:
+ * Copyright (c) 1997 Dan error_act (dma...@jlc.net)
+ * Copyright (c) 1999-2001 Dan Malek d...@embeddedalley.com
+ * Copyright (c) 2000 MontaVista Software, Inc (sou...@mvista.com)
+ * 2006 (c) MontaVista Software, Inc.
+ * Vitaly Bordug vbor...@ru.mvista.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/init.h
+#include linux/of_device.h
+#include linux/spinlock.h
+#include linux/export.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/slab.h
+
+#include linux/io.h
+#include asm/rheap.h
+#include linux/fsl/qe.h
+
+static spinlock_t qe_muram_lock;
+static rh_block_t qe_boot_muram_rh_block[16];
+static rh_info_t qe_muram_info;
+static u8 __iomem *muram_vbase;
+static phys_addr_t muram_pbase;
+
+/* Max address size we deal with */
+#define OF_MAX_ADDR_CELLS 4
+
+int qe_muram_init(void)
+{
+ struct device_node *np;
+ struct resource r;
+ u32 zero[OF_MAX_ADDR_CELLS] = {};
+ resource_size_t max = 0;
+ int i = 0;
+ int ret = 0;
+
+ if (muram_pbase)
+ return 0;
+
+ spin_lock_init(qe_muram_lock);
+ /* initialize the info header */
+ rh_init(qe_muram_info, 1,
+ sizeof(qe_boot_muram_rh_block) /
+ sizeof(qe_boot_muram_rh_block[0]),
+ qe_boot_muram_rh_block);
+
+ np = of_find_compatible_node(NULL, NULL, fsl,qe-muram-data);
+ if (!np) {
+ /* try legacy bindings */
+ np = of_find_node_by_name(NULL, data-only);
+ if (!np) {
+ pr_err(Cannot find CPM muram data node);
+ ret = -ENODEV;
+ goto out;
+ }
+ }
+
+ muram_pbase = of_translate_address(np, zero);
+ if (muram_pbase == (phys_addr_t)OF_BAD_ADDR) {
+ pr_err(Cannot translate zero through CPM muram node);
+ ret = -ENODEV;
+ goto out;
+ }
+
+ while (of_address_to_resource(np, i++, r) == 0) {
+ if (r.end max)
+ max = r.end;
+
+ rh_attach_region(qe_muram_info, r.start - muram_pbase,
+resource_size(r));
+ }
+
+ muram_vbase = ioremap(muram_pbase, max - muram_pbase + 1);
+ if (!muram_vbase) {
+ pr_err(Cannot map CPM muram);
+ ret = -ENOMEM;
+ }
+
+out:
+ of_node_put(np);
+ return ret;
+}
+
+/**
+ * qe_muram_alloc - allocate the requested size worth of multi-user ram
+ * @size: number of bytes to allocate
+ * @align: requested alignment, in bytes
+ *
+ * This function returns an offset into the muram area.
+ * Use qe_dpram_addr() to get the virtual address of the area.
+ * Use qe_muram_free() to free the allocation.
+ */
+unsigned long qe_muram_alloc(unsigned long size, unsigned long align)
+{
+ unsigned long start;
+ unsigned long flags;
+
+ spin_lock_irqsave(qe_muram_lock, flags);
+ qe_muram_info.alignment = align;
+ start = rh_alloc(qe_muram_info, size, commproc);
+ memset(qe_muram_addr(start), 0, size);
+ spin_unlock_irqrestore(qe_muram_lock, flags);
+
+ return start;
+}
+EXPORT_SYMBOL(qe_muram_alloc);
+
+/**
+ * qe_muram_free - free a chunk of multi-user ram
+ * @offset: The beginning of the chunk as returned by qe_muram_alloc().
+ */
+int qe_muram_free(unsigned long offset)
+{
+ int ret;
+ unsigned long flags;
+
+ spin_lock_irqsave(qe_muram_lock, flags);
+ ret = rh_free(qe_muram_info, offset);
+
[PATCH v3 3/3] rheap: move rheap.c from arch/powerpc/lib/ to lib/
qe need to use the rheap, so move it to public directory.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
arch/powerpc/Kconfig| 3 ---
arch/powerpc/include/asm/fsl_85xx_cache_sram.h | 2 +-
arch/powerpc/lib/Makefile | 2 --
arch/powerpc/platforms/44x/Kconfig | 2 +-
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/Kconfig | 2 +-
arch/powerpc/platforms/Kconfig.cputype | 2 +-
arch/powerpc/sysdev/cpm1.c | 2 +-
arch/powerpc/sysdev/cpm2.c | 2 +-
arch/powerpc/sysdev/cpm_common.c| 2 +-
arch/powerpc/sysdev/ppc4xx_ocm.c| 2 +-
drivers/dma/bestcomm/Kconfig| 2 +-
drivers/soc/fsl-qe/Kconfig | 2 +-
drivers/soc/fsl-qe/qe.c | 2 +-
drivers/soc/fsl-qe/qe_common.c | 2 +-
include/linux/fsl/bestcomm/sram.h | 2 +-
{arch/powerpc/include/asm = include/linux/fsl}/rheap.h | 0
lib/Kconfig | 3 +++
lib/Makefile| 2 ++
{arch/powerpc/lib = lib}/rheap.c | 2 +-
20 files changed, 20 insertions(+), 20 deletions(-)
rename {arch/powerpc/include/asm = include/linux/fsl}/rheap.h (100%)
rename {arch/powerpc/lib = lib}/rheap.c (99%)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 007b052..d6a31a6 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -1067,7 +1067,4 @@ config KEYS_COMPAT
source crypto/Kconfig
-config PPC_LIB_RHEAP
- bool
-
source arch/powerpc/kvm/Kconfig
diff --git a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
index 2af2bdc..e57888a 100644
--- a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
+++ b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
@@ -26,7 +26,7 @@
#ifndef __ASM_POWERPC_FSL_85XX_CACHE_SRAM_H__
#define __ASM_POWERPC_FSL_85XX_CACHE_SRAM_H__
-#include asm/rheap.h
+#include linux/fsl/rheap.h
#include linux/spinlock.h
/*
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 59fa2de..c73dff8 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -32,8 +32,6 @@ obj-$(CONFIG_SMP) += locks.o
obj-$(CONFIG_ALTIVEC) += vmx-helper.o
endif
-obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
-
obj-y += code-patching.o
obj-y += feature-fixups.o
obj-$(CONFIG_FTR_FIXUP_SELFTEST) += feature-fixups-test.o
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index 4d88f6a..c7994ff 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -282,7 +282,7 @@ config PPC4xx_GPIO
config PPC4xx_OCM
bool PPC4xx On Chip Memory (OCM) support
depends on 4xx
- select PPC_LIB_RHEAP
+ select LIB_RHEAP
help
Enable OCM support for PowerPC 4xx platforms with on chip memory,
OCM provides the fast place for memory access to improve performance.
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index f22635a..0a7cb9d 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -16,7 +16,7 @@ if PPC32
config FSL_85XX_CACHE_SRAM
bool
- select PPC_LIB_RHEAP
+ select LIB_RHEAP
help
When selected, this option enables cache-sram support
for memory allocation on P1/P2 QorIQ platforms.
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index ae8879c..25740c4 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -281,7 +281,7 @@ config CPM2
bool Enable support for the CPM2 (Communications Processor Module)
depends on (FSL_SOC_BOOKE PPC32) || 8260
select CPM
- select PPC_LIB_RHEAP
+ select LIB_RHEAP
select PPC_PCI_CHOICE
select ARCH_REQUIRE_GPIOLIB
help
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index a41bd02..0bb8c58 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -33,7 +33,7 @@ config PPC_8xx
bool Freescale 8xx
select FSL_SOC
select 8xx
- select PPC_LIB_RHEAP
+ select LIB_RHEAP
config 40x
bool AMCC 40x
diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
index 5e6ff38..c6f5762 100644
--- a/arch/powerpc/sysdev/cpm1.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -38,7 +38,7 @@
#include asm/cpm1.h
#include asm/io.h
#include asm/tlbflush.h
-#include asm/rheap.h
+#include linux/fsl/rheap.h
#include asm/prom.h
#include asm/cpm.h
diff --git
Re: [PATCH 1/2] ipr: Convert to generic DMA API
On Wed, Oct 29, 2014 at 12:34:49PM -0500, Brian King wrote: Acked-by: Brian King brk...@linux.vnet.ibm.com Doesn't apply to me. Brain, can you please resend a rebased version of these two patches with ipr error handlign patch (and anything else ipr related)? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Added rcw registers to global utility registers
From: Igal Liberman igal.liber...@freescale.com
The RCW registers are required for the future clock binding implementation.
Signed-off-by: Igal Liberman igal.liber...@freescale.com
Change-Id: Ic36dd8bc2959aa7f97fb6fd7bbb8420822fef0a9
---
arch/powerpc/include/asm/fsl_guts.h |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/fsl_guts.h
b/arch/powerpc/include/asm/fsl_guts.h
index 193d1f1..38d0b57 100644
--- a/arch/powerpc/include/asm/fsl_guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -68,7 +68,10 @@ struct ccsr_guts {
u8 res0b4[0xc0 - 0xb4];
__be32 iovselsr; /* 0x.00c0 - I/O voltage select status register
Called 'elbcvselcr' on 86xx SOCs */
- u8 res0c4[0x224 - 0xc4];
+ u8 res0c4[0x100 - 0xc4];
+ __be32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
+There are 16 registers */
+ u8 res140[0x224 - 0x140];
__be32 iodelay1; /* 0x.0224 - IO delay control register 1 */
__be32 iodelay2; /* 0x.0228 - IO delay control register 2 */
u8 res22c[0x604 - 0x22c];
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] rheap: move rheap.c from arch/powerpc/lib/ to lib/
On Oct 30, 2014, at 2:31 AM, Zhao Qiang b45...@freescale.com wrote:
qe need to use the rheap, so move it to public directory.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
arch/powerpc/Kconfig| 3 ---
arch/powerpc/include/asm/fsl_85xx_cache_sram.h | 2 +-
arch/powerpc/lib/Makefile | 2 --
arch/powerpc/platforms/44x/Kconfig | 2 +-
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/Kconfig | 2 +-
arch/powerpc/platforms/Kconfig.cputype | 2 +-
arch/powerpc/sysdev/cpm1.c | 2 +-
arch/powerpc/sysdev/cpm2.c | 2 +-
arch/powerpc/sysdev/cpm_common.c| 2 +-
arch/powerpc/sysdev/ppc4xx_ocm.c| 2 +-
drivers/dma/bestcomm/Kconfig| 2 +-
drivers/soc/fsl-qe/Kconfig | 2 +-
drivers/soc/fsl-qe/qe.c | 2 +-
drivers/soc/fsl-qe/qe_common.c | 2 +-
include/linux/fsl/bestcomm/sram.h | 2 +-
{arch/powerpc/include/asm = include/linux/fsl}/rheap.h | 0
lib/Kconfig | 3 +++
lib/Makefile| 2 ++
{arch/powerpc/lib = lib}/rheap.c | 2 +-
20 files changed, 20 insertions(+), 20 deletions(-)
rename {arch/powerpc/include/asm = include/linux/fsl}/rheap.h (100%)
rename {arch/powerpc/lib = lib}/rheap.c (99%)
NAK. As I stated before you need to convert rheap users to lib/genalloc.c
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] QE: move qe code from arch/powerpc to drivers/soc
On Oct 30, 2014, at 2:31 AM, Zhao Qiang b45...@freescale.com wrote:
LS1 is arm cpu and it has qe ip block.
move qe code from platform directory to public directory.
QE is an IP block integrates several comunications peripheral
controllers. It can implement a variety of applications, such
as uart, usb and tdm and so on.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
Changes for v2:
- move code to driver/soc
Changes for v3:
- change drivers/soc/qe to drivers/soc/fsl-qe
arch/powerpc/Kconfig | 2 -
arch/powerpc/platforms/83xx/km83xx.c | 4 +-
arch/powerpc/platforms/83xx/misc.c | 2 +-
arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 +-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 +-
arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 +-
arch/powerpc/platforms/85xx/common.c | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 +-
arch/powerpc/platforms/85xx/twr_p102x.c| 4 +-
arch/powerpc/platforms/Kconfig | 19 -
arch/powerpc/sysdev/Makefile | 1 -
arch/powerpc/sysdev/qe_lib/Kconfig | 27 -
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
drivers/net/ethernet/freescale/ucc_geth.c | 8 ++--
drivers/net/ethernet/freescale/ucc_geth.h | 8 ++--
drivers/soc/Kconfig| 2 +
drivers/soc/Makefile | 1 +
drivers/soc/fsl-qe/Kconfig | 45 ++
.../sysdev/qe_lib = drivers/soc/fsl-qe}/Makefile | 0
.../sysdev/qe_lib = drivers/soc/fsl-qe}/gpio.c| 2 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/qe.c | 4 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/qe_ic.c | 2 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/qe_ic.h | 2 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/qe_io.c | 2 +-
.../sysdev/qe_lib = drivers/soc/fsl-qe}/ucc.c | 6 +--
.../qe_lib = drivers/soc/fsl-qe}/ucc_fast.c | 8 ++--
.../qe_lib = drivers/soc/fsl-qe}/ucc_slow.c | 8 ++--
.../sysdev/qe_lib = drivers/soc/fsl-qe}/usb.c | 4 +-
drivers/spi/spi-fsl-cpm.c | 2 +-
drivers/tty/serial/ucc_uart.c | 2 +-
drivers/usb/gadget/fsl_qe_udc.c| 2 +-
drivers/usb/host/fhci-hcd.c| 2 +-
drivers/usb/host/fhci-hub.c| 2 +-
drivers/usb/host/fhci-sched.c | 2 +-
drivers/usb/host/fhci.h| 4 +-
.../include/asm = include/linux/fsl}/immap_qe.h | 0
.../powerpc/include/asm = include/linux/fsl}/qe.h | 2 +-
.../include/asm = include/linux/fsl}/qe_ic.h | 0
.../include/asm = include/linux/fsl}/ucc.h| 4 +-
.../include/asm = include/linux/fsl}/ucc_fast.h | 6 +--
.../include/asm = include/linux/fsl}/ucc_slow.h | 6 +--
44 files changed, 112 insertions(+), 113 deletions(-)
delete mode 100644 arch/powerpc/sysdev/qe_lib/Kconfig
create mode 100644 drivers/soc/fsl-qe/Kconfig
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/Makefile (100%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/gpio.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/qe.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/qe_ic.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/qe_ic.h (98%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/qe_io.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/ucc.c (98%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/ucc_fast.c (98%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/ucc_slow.c (98%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl-qe}/usb.c (96%)
rename {arch/powerpc/include/asm = include/linux/fsl}/immap_qe.h (100%)
rename {arch/powerpc/include/asm = include/linux/fsl}/qe.h (99%)
rename {arch/powerpc/include/asm = include/linux/fsl}/qe_ic.h (100%)
rename {arch/powerpc/include/asm = include/linux/fsl}/ucc.h (96%)
rename {arch/powerpc/include/asm = include/linux/fsl}/ucc_fast.h (98%)
rename {arch/powerpc/include/asm = include/linux/fsl}/ucc_slow.h (99%)
So you should be moving things to drivers/soc/fsl/qe/ not drivers/soc/fsl-qe/
The headers should be in include/soc/fsl, not include/linux/fsl
In addition before this move is accepted, other changes need to be made to
convert to using standard frameworks for various functionality in QE lib.
1. gpio.c - needs to be converted to GPIO framework and placed in drivers/gpio
2. qe_ic* should probably move into drivers/irqchip
3. qe_io.c should be converted over to pinmux and put in drivers/pinctrl
4. Some of the clock could should
Re: [PATCH 1/2] ipr: Convert to generic DMA API
On 10/30/2014 04:11 AM, Christoph Hellwig wrote: On Wed, Oct 29, 2014 at 12:34:49PM -0500, Brian King wrote: Acked-by: Brian King brk...@linux.vnet.ibm.com Doesn't apply to me. Brain, can you please resend a rebased version of these two patches with ipr error handlign patch (and anything else ipr related)? Sorry. Let me rebase on top of your tree... -Brian -- Brian King Power Linux I/O IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/dts: Factorize the clock control node
Hello Scott,
On 10/28/2014 06:21 PM, Scott Wood wrote:
On Wed, 2014-10-22 at 09:42 -0500, Emil Medve wrote:
Signed-off-by: Emil Medve emilian.me...@freescale.com
Change-Id: I25ce24a25862b4ca460164159867abefe00ccdd1
Please remove gerrit stuff prior to submitting.
I did remove the bulk of it. I wanted to keep the Change-Id so I can
easily correlate the upstream patches with the sordid internal history.
Seems the upstream history has enough instances of 'Change-Id' for this
not to be an issue
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi
new file mode 100644
index 000..4871048
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi
@@ -0,0 +1,78 @@
+/*
+ * QorIQ clock control device tree stub [ controller @ offset 0xe1000 ]
+ *
+ * Copyright 2014 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.
+ */
+
+global-utilities@e1000 {
+compatible = fsl,qoriq-clockgen-1.0;
+ranges = 0x0 0xe1000 0x1000;
+reg = 0xe1000 0x1000;
+clock-frequency = 0;
+#address-cells = 1;
+#size-cells = 1;
+
+sysclk: sysclk {
+#clock-cells = 0;
+compatible = fsl,qoriq-sysclk-1.0, fixed-clock;
+clock-output-names = sysclk;
+};
+pll0: pll0@800 {
+#clock-cells = 1;
+reg = 0x800 0x4;
+compatible = fsl,qoriq-core-pll-1.0;
+clocks = sysclk;
+clock-output-names = pll0, pll0-div2;
+};
+pll1: pll1@820 {
+#clock-cells = 1;
+reg = 0x820 0x4;
+compatible = fsl,qoriq-core-pll-1.0;
+clocks = sysclk;
+clock-output-names = pll1, pll1-div2;
+};
+mux0: mux0@0 {
+#clock-cells = 0;
+reg = 0x0 0x4;
+compatible = fsl,qoriq-core-mux-1.0;
+clocks = pll0 0, pll0 1, pll1 0, pll1 1;
+clock-names = pll0, pll0-div2, pll1, pll1-div2;
+clock-output-names = cmux0;
+};
+mux1: mux1@20 {
+#clock-cells = 0;
+reg = 0x20 0x4;
+compatible = fsl,qoriq-core-mux-1.0;
+clocks = pll0 0, pll0 1, pll1 0, pll1 1;
+clock-names = pll0, pll0-div2, pll1, pll1-div2;
+clock-output-names = cmux1;
+};
+};
I don't think the mux stuff belongs here, given that clockgen2.dtsi
doesn't have it, and I saw at least one clockgen1 user needing to
supplement this with more muxes.
The intent was to put here devices/nodes that are common per chassis
from the low to high end. Specific SoC would change/augment this as
appropriate. I could have put each node in its own file as we've done
elsewhere, but I thought it would be too much
Yes, chassis v1 and v2 have differences, but that's not unexpected
@@ -1068,7 +1043,6 @@
clocks = sysclk;
clock-output-names = pll2, pll2-div2, pll2-div4;
};
-
pll3: pll3@860 {
#clock-cells = 1;
reg = 0x860 0x4;
@@ -1076,7 +1050,6 @@
clocks = sysclk;
clock-output-names =
Re: [PATCH] powerpc: Added rcw registers to global utility registers
On 10/30/2014 04:15 AM, Igal.Liberman wrote: From: Igal Liberman igal.liber...@freescale.com The RCW registers are required for the future clock binding implementation. Signed-off-by: Igal Liberman igal.liber...@freescale.com Change-Id: Ic36dd8bc2959aa7f97fb6fd7bbb8420822fef0a9 --- arch/powerpc/include/asm/fsl_guts.h |5 - 1 file changed, 4 insertions(+), 1 deletion(-) Signed-off-by: Emil Medve emilian.me...@freescale.com Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Added rcw registers to global utility registers
On Thu, 2014-10-30 at 08:59 -0500, Emil Medve wrote: On 10/30/2014 04:15 AM, Igal.Liberman wrote: From: Igal Liberman igal.liber...@freescale.com The RCW registers are required for the future clock binding implementation. Signed-off-by: Igal Liberman igal.liber...@freescale.com Change-Id: Ic36dd8bc2959aa7f97fb6fd7bbb8420822fef0a9 --- arch/powerpc/include/asm/fsl_guts.h |5 - 1 file changed, 4 insertions(+), 1 deletion(-) Signed-off-by: Emil Medve emilian.me...@freescale.com How were you involved in the patch or its submission? Did you mean Reviewed-by or similar? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
On Wed, 2014-10-29 at 23:32 -0500, Emil Medve wrote: Hello Scott, On 10/29/2014 05:16 PM, Scott Wood wrote: On Wed, 2014-10-29 at 16:40 -0500, Emil Medve wrote: Hello Scott, On 10/28/2014 01:08 PM, Scott Wood wrote: On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote: On Oct 22, 2014, at 9:09 AM, Emil Medve emilian.me...@freescale.com wrote: The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA). BMan supports hardware allocation and deallocation of buffers belonging to pools originally created by software with configurable depletion thresholds. This binding covers the CCSR space programming model Signed-off-by: Emil Medve emilian.me...@freescale.com Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2 --- .../devicetree/bindings/powerpc/fsl/bman.txt | 98 ++ 1 file changed, 98 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well? The hardware on the ARM SoCs is different enough that I'm not sure the same binding will cover it. That said, putting things under arch should be a last resort if nowhere else fits. OTC started ported the driver to the the ARM SoC and the feedback has been that the driver needed minimal changes. The IOMMU has been the only area of concern, and a small change to the binding has been suggested Do we need something in the binding to indicate device endianness? As I said, I didn't have enough exposure to the ARM SoC so I can't answer that If this binding is going to continue to be relevant to future DPAA generations, I think we really ought to deal with the possibility that there is more than one datapath instance I'm unsure how relevant this will be going forward. In LS2 B/QMan is abstracted/hidden away behind the MC (firmware). This is why I was wondering whether the binding would be at all the same... I wouldn't over-engineer this without a clear picture of what multiple data-paths per SoC even means at this point I don't think it's over-engineering. Assuming only one instance of something is generally sloppy engineering. Linux doesn't need to actually pay attention to it until and unless it becomes necessary, but it's good to have the information in the device tree up front. by having phandles and/or a parent container to connect the related components. Connecting the related components is beyond the scope of this binding. It will soon hit the e-mail list(s) as part of upstreaming the Ethernet driver So you want us to merge this binding without being told how this works? Or by soon do you mean before this binding is accepted? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
Hello Scott, On 10/30/2014 09:51 AM, Scott Wood wrote: On Wed, 2014-10-29 at 23:32 -0500, Emil Medve wrote: Hello Scott, On 10/29/2014 05:16 PM, Scott Wood wrote: On Wed, 2014-10-29 at 16:40 -0500, Emil Medve wrote: Hello Scott, On 10/28/2014 01:08 PM, Scott Wood wrote: On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote: On Oct 22, 2014, at 9:09 AM, Emil Medve emilian.me...@freescale.com wrote: The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA). BMan supports hardware allocation and deallocation of buffers belonging to pools originally created by software with configurable depletion thresholds. This binding covers the CCSR space programming model Signed-off-by: Emil Medve emilian.me...@freescale.com Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2 --- .../devicetree/bindings/powerpc/fsl/bman.txt | 98 ++ 1 file changed, 98 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well? The hardware on the ARM SoCs is different enough that I'm not sure the same binding will cover it. That said, putting things under arch should be a last resort if nowhere else fits. OTC started ported the driver to the the ARM SoC and the feedback has been that the driver needed minimal changes. The IOMMU has been the only area of concern, and a small change to the binding has been suggested Do we need something in the binding to indicate device endianness? As I said, I didn't have enough exposure to the ARM SoC so I can't answer that If this binding is going to continue to be relevant to future DPAA generations, I think we really ought to deal with the possibility that there is more than one datapath instance I'm unsure how relevant this will be going forward. In LS2 B/QMan is abstracted/hidden away behind the MC (firmware). This is why I was wondering whether the binding would be at all the same... I wouldn't over-engineer this without a clear picture of what multiple data-paths per SoC even means at this point I don't think it's over-engineering. Assuming only one instance of something is generally sloppy engineering. Linux doesn't need to actually pay attention to it until and unless it becomes necessary, but it's good to have the information in the device tree up front. I asked around and the multiple data-path SoC seems to be at this point a speculation. It seems unclear how would it work, what requirements/problems it would address/solve, what programming interface it would have. I'm not sure what do you suggest we do In order to reduce the sloppiness of this binding. I'll add a memory-region phandle to connect each B/QMan node to their reserved-memory node by having phandles and/or a parent container to connect the related components. Connecting the related components is beyond the scope of this binding. It will soon hit the e-mail list(s) as part of upstreaming the Ethernet driver So you want us to merge this binding without being told how this works? This binding stands on its own and each block (B/QMan) can be used for some useful purpose by itself. All other blocks/applications that use the B/QMan use the same basic interface acquire/release a buffer and enqueue/dequeue a packet. I'm not sure what you feel I didn't share Or by soon do you mean before this binding is accepted? No. The Ethernet driver, the QI SEC driver, RMan driver, etc. employ the B/QMan and *other* hardware resources in some specific way. I don't think their binding/drivers condition accepting the B/QMan binding/driver Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
On Thu, 2014-10-30 at 11:19 -0500, Emil Medve wrote: Hello Scott, On 10/30/2014 09:51 AM, Scott Wood wrote: On Wed, 2014-10-29 at 23:32 -0500, Emil Medve wrote: Hello Scott, On 10/29/2014 05:16 PM, Scott Wood wrote: On Wed, 2014-10-29 at 16:40 -0500, Emil Medve wrote: Hello Scott, On 10/28/2014 01:08 PM, Scott Wood wrote: On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote: On Oct 22, 2014, at 9:09 AM, Emil Medve emilian.me...@freescale.com wrote: The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA). BMan supports hardware allocation and deallocation of buffers belonging to pools originally created by software with configurable depletion thresholds. This binding covers the CCSR space programming model Signed-off-by: Emil Medve emilian.me...@freescale.com Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2 --- .../devicetree/bindings/powerpc/fsl/bman.txt | 98 ++ 1 file changed, 98 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well? The hardware on the ARM SoCs is different enough that I'm not sure the same binding will cover it. That said, putting things under arch should be a last resort if nowhere else fits. OTC started ported the driver to the the ARM SoC and the feedback has been that the driver needed minimal changes. The IOMMU has been the only area of concern, and a small change to the binding has been suggested Do we need something in the binding to indicate device endianness? As I said, I didn't have enough exposure to the ARM SoC so I can't answer that If this binding is going to continue to be relevant to future DPAA generations, I think we really ought to deal with the possibility that there is more than one datapath instance I'm unsure how relevant this will be going forward. In LS2 B/QMan is abstracted/hidden away behind the MC (firmware). This is why I was wondering whether the binding would be at all the same... I wouldn't over-engineer this without a clear picture of what multiple data-paths per SoC even means at this point I don't think it's over-engineering. Assuming only one instance of something is generally sloppy engineering. Linux doesn't need to actually pay attention to it until and unless it becomes necessary, but it's good to have the information in the device tree up front. I asked around and the multiple data-path SoC seems to be at this point a speculation. It seems unclear how would it work, what requirements/problems it would address/solve, what programming interface it would have. I'm not sure what do you suggest we do In order to reduce the sloppiness of this binding. I'll add a memory-region phandle to connect each B/QMan node to their reserved-memory node Thanks, that's the sort of thing I was looking for. There should also be a connection from the portals to the relevant bqman node, though we need to deal with the possibility that the bqman node may not be present (e.g. in a vm guest). by having phandles and/or a parent container to connect the related components. Connecting the related components is beyond the scope of this binding. It will soon hit the e-mail list(s) as part of upstreaming the Ethernet driver So you want us to merge this binding without being told how this works? This binding stands on its own and each block (B/QMan) can be used for some useful purpose by itself. All other blocks/applications that use the B/QMan use the same basic interface acquire/release a buffer and enqueue/dequeue a packet. I'm not sure what you feel I didn't share So there's no hardware connection between the bman and qman themselves? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
-Original Message- From: Linuxppc-dev [mailto:linuxppc-dev- bounces+varun.sethi=freescale@lists.ozlabs.org] On Behalf Of Emil Medve Sent: Thursday, October 30, 2014 3:10 AM To: Wood Scott-B07421; Kumar Gala Cc: mark.rutl...@arm.com; devicet...@vger.kernel.org; pawel.m...@arm.com; cor...@lwn.net; Thorpe Geoff-R01361; ijc+devicet...@hellion.org.uk; linux-...@vger.kernel.org; linuxppc- d...@ozlabs.org; robh...@kernel.org Subject: Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan Hello Scott, On 10/28/2014 01:08 PM, Scott Wood wrote: On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote: On Oct 22, 2014, at 9:09 AM, Emil Medve emilian.me...@freescale.com wrote: The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA). BMan supports hardware allocation and deallocation of buffers belonging to pools originally created by software with configurable depletion thresholds. This binding covers the CCSR space programming model Signed-off-by: Emil Medve emilian.me...@freescale.com Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2 --- .../devicetree/bindings/powerpc/fsl/bman.txt | 98 ++ 1 file changed, 98 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well? The hardware on the ARM SoCs is different enough that I'm not sure the same binding will cover it. That said, putting things under arch should be a last resort if nowhere else fits. OTC started ported the driver to the the ARM SoC and the feedback has been that the driver needed minimal changes. The IOMMU has been the only area of concern, and a small change to the binding has been suggested IOMMU specific binding would be different. The binding would have to comply to the arm-smmu binding (which needs to be updated). -Varun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
Hello Scott, On 10/30/2014 11:29 AM, Scott Wood wrote: On Thu, 2014-10-30 at 11:19 -0500, Emil Medve wrote: Hello Scott, On 10/30/2014 09:51 AM, Scott Wood wrote: On Wed, 2014-10-29 at 23:32 -0500, Emil Medve wrote: Hello Scott, On 10/29/2014 05:16 PM, Scott Wood wrote: On Wed, 2014-10-29 at 16:40 -0500, Emil Medve wrote: Hello Scott, On 10/28/2014 01:08 PM, Scott Wood wrote: On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote: On Oct 22, 2014, at 9:09 AM, Emil Medve emilian.me...@freescale.com wrote: The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA). BMan supports hardware allocation and deallocation of buffers belonging to pools originally created by software with configurable depletion thresholds. This binding covers the CCSR space programming model Signed-off-by: Emil Medve emilian.me...@freescale.com Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2 --- .../devicetree/bindings/powerpc/fsl/bman.txt | 98 ++ 1 file changed, 98 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well? The hardware on the ARM SoCs is different enough that I'm not sure the same binding will cover it. That said, putting things under arch should be a last resort if nowhere else fits. OTC started ported the driver to the the ARM SoC and the feedback has been that the driver needed minimal changes. The IOMMU has been the only area of concern, and a small change to the binding has been suggested Do we need something in the binding to indicate device endianness? As I said, I didn't have enough exposure to the ARM SoC so I can't answer that If this binding is going to continue to be relevant to future DPAA generations, I think we really ought to deal with the possibility that there is more than one datapath instance I'm unsure how relevant this will be going forward. In LS2 B/QMan is abstracted/hidden away behind the MC (firmware). This is why I was wondering whether the binding would be at all the same... I wouldn't over-engineer this without a clear picture of what multiple data-paths per SoC even means at this point I don't think it's over-engineering. Assuming only one instance of something is generally sloppy engineering. Linux doesn't need to actually pay attention to it until and unless it becomes necessary, but it's good to have the information in the device tree up front. I asked around and the multiple data-path SoC seems to be at this point a speculation. It seems unclear how would it work, what requirements/problems it would address/solve, what programming interface it would have. I'm not sure what do you suggest we do In order to reduce the sloppiness of this binding. I'll add a memory-region phandle to connect each B/QMan node to their reserved-memory node Thanks, that's the sort of thing I was looking for. There should also be a connection from the portals to the relevant bqman node Nothing in the current programing model requires a portal to know its B/QMan parent. Should I add a phandle of sorts anyway? though we need to deal with the possibility that the bqman node may not be present (e.g. in a vm guest). by having phandles and/or a parent container to connect the related components. Connecting the related components is beyond the scope of this binding. It will soon hit the e-mail list(s) as part of upstreaming the Ethernet driver So you want us to merge this binding without being told how this works? This binding stands on its own and each block (B/QMan) can be used for some useful purpose by itself. All other blocks/applications that use the B/QMan use the same basic interface acquire/release a buffer and enqueue/dequeue a packet. I'm not sure what you feel I didn't share So there's no hardware connection between the bman and qman themselves? Not a single one Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
On Wed, Oct 29, 2014 at 11:12 PM, Denis Kirjanov k...@linux-powerpc.org wrote: Add BPF extension SKF_AD_PKTTYPE to ppc JIT to load skb-pkt_type field. Before: [ 88.262622] test_bpf: #11 LD_IND_NET 86 97 99 PASS [ 88.265740] test_bpf: #12 LD_PKTTYPE 109 107 PASS After: [ 80.605964] test_bpf: #11 LD_IND_NET 44 40 39 PASS [ 80.607370] test_bpf: #12 LD_PKTTYPE 9 9 PASS if you'd only quoted #12, it would all make sense ;) but #11 test is not using PKTTYPE. So your patch shouldn't make a difference. Are these numbers with JIT on and off? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
On Thu, 2014-10-30 at 11:45 -0500, Emil Medve wrote: Hello Scott, On 10/30/2014 11:29 AM, Scott Wood wrote: On Thu, 2014-10-30 at 11:19 -0500, Emil Medve wrote: Hello Scott, On 10/30/2014 09:51 AM, Scott Wood wrote: On Wed, 2014-10-29 at 23:32 -0500, Emil Medve wrote: Hello Scott, On 10/29/2014 05:16 PM, Scott Wood wrote: On Wed, 2014-10-29 at 16:40 -0500, Emil Medve wrote: Hello Scott, On 10/28/2014 01:08 PM, Scott Wood wrote: On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote: On Oct 22, 2014, at 9:09 AM, Emil Medve emilian.me...@freescale.com wrote: The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA). BMan supports hardware allocation and deallocation of buffers belonging to pools originally created by software with configurable depletion thresholds. This binding covers the CCSR space programming model Signed-off-by: Emil Medve emilian.me...@freescale.com Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2 --- .../devicetree/bindings/powerpc/fsl/bman.txt | 98 ++ 1 file changed, 98 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well? The hardware on the ARM SoCs is different enough that I'm not sure the same binding will cover it. That said, putting things under arch should be a last resort if nowhere else fits. OTC started ported the driver to the the ARM SoC and the feedback has been that the driver needed minimal changes. The IOMMU has been the only area of concern, and a small change to the binding has been suggested Do we need something in the binding to indicate device endianness? As I said, I didn't have enough exposure to the ARM SoC so I can't answer that If this binding is going to continue to be relevant to future DPAA generations, I think we really ought to deal with the possibility that there is more than one datapath instance I'm unsure how relevant this will be going forward. In LS2 B/QMan is abstracted/hidden away behind the MC (firmware). This is why I was wondering whether the binding would be at all the same... I wouldn't over-engineer this without a clear picture of what multiple data-paths per SoC even means at this point I don't think it's over-engineering. Assuming only one instance of something is generally sloppy engineering. Linux doesn't need to actually pay attention to it until and unless it becomes necessary, but it's good to have the information in the device tree up front. I asked around and the multiple data-path SoC seems to be at this point a speculation. It seems unclear how would it work, what requirements/problems it would address/solve, what programming interface it would have. I'm not sure what do you suggest we do In order to reduce the sloppiness of this binding. I'll add a memory-region phandle to connect each B/QMan node to their reserved-memory node Thanks, that's the sort of thing I was looking for. There should also be a connection from the portals to the relevant bqman node Nothing in the current programing model requires a portal to know its B/QMan parent. Should I add a phandle of sorts anyway? Well, you at least have the requirement to initialize the qbman parent before using its portals, and you need to use the portals that go with the qbman instances that are connected to the device you want to access... So there's no hardware connection between the bman and qman themselves? Not a single one OK. Please keep in mind that I haven't worked with this stuff as closely as you have. :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
Hello Scott, On 10/30/2014 04:26 PM, Scott Wood wrote: On Thu, 2014-10-30 at 11:45 -0500, Emil Medve wrote: Hello Scott, On 10/30/2014 11:29 AM, Scott Wood wrote: On Thu, 2014-10-30 at 11:19 -0500, Emil Medve wrote: Hello Scott, On 10/30/2014 09:51 AM, Scott Wood wrote: On Wed, 2014-10-29 at 23:32 -0500, Emil Medve wrote: Hello Scott, On 10/29/2014 05:16 PM, Scott Wood wrote: On Wed, 2014-10-29 at 16:40 -0500, Emil Medve wrote: Hello Scott, On 10/28/2014 01:08 PM, Scott Wood wrote: On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote: On Oct 22, 2014, at 9:09 AM, Emil Medve emilian.me...@freescale.com wrote: The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA). BMan supports hardware allocation and deallocation of buffers belonging to pools originally created by software with configurable depletion thresholds. This binding covers the CCSR space programming model Signed-off-by: Emil Medve emilian.me...@freescale.com Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2 --- .../devicetree/bindings/powerpc/fsl/bman.txt | 98 ++ 1 file changed, 98 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well? The hardware on the ARM SoCs is different enough that I'm not sure the same binding will cover it. That said, putting things under arch should be a last resort if nowhere else fits. OTC started ported the driver to the the ARM SoC and the feedback has been that the driver needed minimal changes. The IOMMU has been the only area of concern, and a small change to the binding has been suggested Do we need something in the binding to indicate device endianness? As I said, I didn't have enough exposure to the ARM SoC so I can't answer that If this binding is going to continue to be relevant to future DPAA generations, I think we really ought to deal with the possibility that there is more than one datapath instance I'm unsure how relevant this will be going forward. In LS2 B/QMan is abstracted/hidden away behind the MC (firmware). This is why I was wondering whether the binding would be at all the same... I wouldn't over-engineer this without a clear picture of what multiple data-paths per SoC even means at this point I don't think it's over-engineering. Assuming only one instance of something is generally sloppy engineering. Linux doesn't need to actually pay attention to it until and unless it becomes necessary, but it's good to have the information in the device tree up front. I asked around and the multiple data-path SoC seems to be at this point a speculation. It seems unclear how would it work, what requirements/problems it would address/solve, what programming interface it would have. I'm not sure what do you suggest we do In order to reduce the sloppiness of this binding. I'll add a memory-region phandle to connect each B/QMan node to their reserved-memory node Thanks, that's the sort of thing I was looking for. There should also be a connection from the portals to the relevant bqman node Nothing in the current programing model requires a portal to know its B/QMan parent. Should I add a phandle of sorts anyway? Well, you at least have the requirement to initialize the qbman parent before using its portals, and you need to use the portals that go with the qbman instances that are connected to the device you want to access... So there's no hardware connection between the bman and qman themselves? Not a single one OK. Please keep in mind that I haven't worked with this stuff as closely as you have. :-) Huh? What do you mean? Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] ipr: Convert to generic DMA API
From: Anton Blanchard an...@samba.org
Even though the ipr driver is only used on PCI, convert it
to use the generic DMA API.
Signed-off-by: Anton Blanchard an...@samba.org
Signed-off-by: Brian King brk...@linux.vnet.ibm.com
---
drivers/scsi/ipr.c | 103 +++--
drivers/scsi/ipr.h |2 -
2 files changed, 54 insertions(+), 51 deletions(-)
diff -puN drivers/scsi/ipr.c~ipr_convert_to_generic_DMA_API drivers/scsi/ipr.c
--- scsi-queue/drivers/scsi/ipr.c~ipr_convert_to_generic_DMA_API
2014-10-30 17:15:26.135856602 -0500
+++ scsi-queue-bjking1/drivers/scsi/ipr.c 2014-10-30 17:15:26.144856521
-0500
@@ -3942,8 +3942,9 @@ static int ipr_update_ioa_ucode(struct i
return -EIO;
}
- sglist-num_dma_sg = pci_map_sg(ioa_cfg-pdev, sglist-scatterlist,
- sglist-num_sg, DMA_TO_DEVICE);
+ sglist-num_dma_sg = dma_map_sg(ioa_cfg-pdev-dev,
+ sglist-scatterlist, sglist-num_sg,
+ DMA_TO_DEVICE);
if (!sglist-num_dma_sg) {
spin_unlock_irqrestore(ioa_cfg-host-host_lock, lock_flags);
@@ -5585,7 +5586,7 @@ static int ipr_build_ioadl64(struct ipr_
nseg = scsi_dma_map(scsi_cmd);
if (nseg 0) {
if (printk_ratelimit())
- dev_err(ioa_cfg-pdev-dev, pci_map_sg failed!\n);
+ dev_err(ioa_cfg-pdev-dev, scsi_dma_map failed!\n);
return -1;
}
@@ -5636,7 +5637,7 @@ static int ipr_build_ioadl(struct ipr_io
nseg = scsi_dma_map(scsi_cmd);
if (nseg 0) {
- dev_err(ioa_cfg-pdev-dev, pci_map_sg failed!\n);
+ dev_err(ioa_cfg-pdev-dev, scsi_dma_map failed!\n);
return -1;
}
@@ -8431,7 +8432,7 @@ static int ipr_reset_ucode_download_done
struct ipr_ioa_cfg *ioa_cfg = ipr_cmd-ioa_cfg;
struct ipr_sglist *sglist = ioa_cfg-ucode_sglist;
- pci_unmap_sg(ioa_cfg-pdev, sglist-scatterlist,
+ dma_unmap_sg(ioa_cfg-pdev-dev, sglist-scatterlist,
sglist-num_sg, DMA_TO_DEVICE);
ipr_cmd-job_step = ipr_reset_alert;
@@ -8871,7 +8872,7 @@ static void ipr_free_cmd_blks(struct ipr
for (i = 0; i IPR_NUM_CMD_BLKS; i++) {
if (ioa_cfg-ipr_cmnd_list[i])
- pci_pool_free(ioa_cfg-ipr_cmd_pool,
+ dma_pool_free(ioa_cfg-ipr_cmd_pool,
ioa_cfg-ipr_cmnd_list[i],
ioa_cfg-ipr_cmnd_list_dma[i]);
@@ -8879,7 +8880,7 @@ static void ipr_free_cmd_blks(struct ipr
}
if (ioa_cfg-ipr_cmd_pool)
- pci_pool_destroy(ioa_cfg-ipr_cmd_pool);
+ dma_pool_destroy(ioa_cfg-ipr_cmd_pool);
kfree(ioa_cfg-ipr_cmnd_list);
kfree(ioa_cfg-ipr_cmnd_list_dma);
@@ -8900,25 +8901,24 @@ static void ipr_free_mem(struct ipr_ioa_
int i;
kfree(ioa_cfg-res_entries);
- pci_free_consistent(ioa_cfg-pdev, sizeof(struct ipr_misc_cbs),
- ioa_cfg-vpd_cbs, ioa_cfg-vpd_cbs_dma);
+ dma_free_coherent(ioa_cfg-pdev-dev, sizeof(struct ipr_misc_cbs),
+ ioa_cfg-vpd_cbs, ioa_cfg-vpd_cbs_dma);
ipr_free_cmd_blks(ioa_cfg);
for (i = 0; i ioa_cfg-hrrq_num; i++)
- pci_free_consistent(ioa_cfg-pdev,
- sizeof(u32) * ioa_cfg-hrrq[i].size,
- ioa_cfg-hrrq[i].host_rrq,
- ioa_cfg-hrrq[i].host_rrq_dma);
+ dma_free_coherent(ioa_cfg-pdev-dev,
+ sizeof(u32) * ioa_cfg-hrrq[i].size,
+ ioa_cfg-hrrq[i].host_rrq,
+ ioa_cfg-hrrq[i].host_rrq_dma);
- pci_free_consistent(ioa_cfg-pdev, ioa_cfg-cfg_table_size,
- ioa_cfg-u.cfg_table,
- ioa_cfg-cfg_table_dma);
+ dma_free_coherent(ioa_cfg-pdev-dev, ioa_cfg-cfg_table_size,
+ ioa_cfg-u.cfg_table, ioa_cfg-cfg_table_dma);
for (i = 0; i IPR_NUM_HCAMS; i++) {
- pci_free_consistent(ioa_cfg-pdev,
- sizeof(struct ipr_hostrcb),
- ioa_cfg-hostrcb[i],
- ioa_cfg-hostrcb_dma[i]);
+ dma_free_coherent(ioa_cfg-pdev-dev,
+ sizeof(struct ipr_hostrcb),
+ ioa_cfg-hostrcb[i],
+ ioa_cfg-hostrcb_dma[i]);
}
ipr_free_dump(ioa_cfg);
@@ -8979,7 +8979,7 @@ static int ipr_alloc_cmd_blks(struct ipr
dma_addr_t dma_addr;
int i, entries_each_hrrq, hrrq_id = 0;
- ioa_cfg-ipr_cmd_pool =
[PATCH 3/3] ipr: Wait for aborted command responses
Fixes a race condition in abort handling that was injected
when multiple interrupt support was added. When only a single
interrupt is present, the adapter guarantees it will send
responses for aborted commands prior to the response for the
abort command itself. With multiple interrupts, these responses
generally come back on different interrupts, so we need to
ensure the abort thread waits until the aborted command is
complete so we don't perform a double completion. This race
condition was being hit frequently in environments which
were triggering command timeouts, which was resulting in
a double completion causing a kernel oops.
Cc: sta...@vger.kernel.org
Signed-off-by: Brian King brk...@linux.vnet.ibm.com
---
drivers/scsi/ipr.c | 92 +
drivers/scsi/ipr.h |1
2 files changed, 93 insertions(+)
diff -puN drivers/scsi/ipr.c~ipr_eh_wait drivers/scsi/ipr.c
--- scsi-queue/drivers/scsi/ipr.c~ipr_eh_wait 2014-10-30 17:15:37.302753120
-0500
+++ scsi-queue-bjking1/drivers/scsi/ipr.c 2014-10-30 17:15:37.311753039
-0500
@@ -683,6 +683,7 @@ static void ipr_init_ipr_cmnd(struct ipr
ipr_reinit_ipr_cmnd(ipr_cmd);
ipr_cmd-u.scratch = 0;
ipr_cmd-sibling = NULL;
+ ipr_cmd-eh_comp = NULL;
ipr_cmd-fast_done = fast_done;
init_timer(ipr_cmd-timer);
}
@@ -848,6 +849,8 @@ static void ipr_scsi_eh_done(struct ipr_
scsi_dma_unmap(ipr_cmd-scsi_cmd);
scsi_cmd-scsi_done(scsi_cmd);
+ if (ipr_cmd-eh_comp)
+ complete(ipr_cmd-eh_comp);
list_add_tail(ipr_cmd-queue, ipr_cmd-hrrq-hrrq_free_q);
}
@@ -4854,6 +4857,84 @@ static int ipr_slave_alloc(struct scsi_d
return rc;
}
+/**
+ * ipr_match_lun - Match function for specified LUN
+ * @ipr_cmd: ipr command struct
+ * @device:device to match (sdev)
+ *
+ * Returns:
+ * 1 if command matches sdev / 0 if command does not match sdev
+ **/
+static int ipr_match_lun(struct ipr_cmnd *ipr_cmd, void *device)
+{
+ if (ipr_cmd-scsi_cmd ipr_cmd-scsi_cmd-device == device)
+ return 1;
+ return 0;
+}
+
+/**
+ * ipr_wait_for_ops - Wait for matching commands to complete
+ * @ipr_cmd: ipr command struct
+ * @device:device to match (sdev)
+ * @match: match function to use
+ *
+ * Returns:
+ * SUCCESS / FAILED
+ **/
+static int ipr_wait_for_ops(struct ipr_ioa_cfg *ioa_cfg, void *device,
+ int (*match)(struct ipr_cmnd *, void *))
+{
+ struct ipr_cmnd *ipr_cmd;
+ int wait;
+ unsigned long flags;
+ struct ipr_hrr_queue *hrrq;
+ signed long timeout = IPR_ABORT_TASK_TIMEOUT;
+ DECLARE_COMPLETION_ONSTACK(comp);
+
+ ENTER;
+ do {
+ wait = 0;
+
+ for_each_hrrq(hrrq, ioa_cfg) {
+ spin_lock_irqsave(hrrq-lock, flags);
+ list_for_each_entry(ipr_cmd, hrrq-hrrq_pending_q,
queue) {
+ if (match(ipr_cmd, device)) {
+ ipr_cmd-eh_comp = comp;
+ wait++;
+ }
+ }
+ spin_unlock_irqrestore(hrrq-lock, flags);
+ }
+
+ if (wait) {
+ timeout = wait_for_completion_timeout(comp, timeout);
+
+ if (!timeout) {
+ wait = 0;
+
+ for_each_hrrq(hrrq, ioa_cfg) {
+ spin_lock_irqsave(hrrq-lock, flags);
+ list_for_each_entry(ipr_cmd,
hrrq-hrrq_pending_q, queue) {
+ if (match(ipr_cmd, device)) {
+ ipr_cmd-eh_comp = NULL;
+ wait++;
+ }
+ }
+ spin_unlock_irqrestore(hrrq-lock,
flags);
+ }
+
+ if (wait)
+ dev_err(ioa_cfg-pdev-dev, Timed out
waiting for aborted commands\n);
+ LEAVE;
+ return wait ? FAILED : SUCCESS;
+ }
+ }
+ } while (wait);
+
+ LEAVE;
+ return SUCCESS;
+}
+
static int ipr_eh_host_reset(struct scsi_cmnd *cmd)
{
struct ipr_ioa_cfg *ioa_cfg;
@@ -5073,11 +5154,17 @@ static int __ipr_eh_dev_reset(struct scs
static int ipr_eh_dev_reset(struct scsi_cmnd *cmd)
{
int rc;
+ struct ipr_ioa_cfg *ioa_cfg;
+
+ ioa_cfg = (struct ipr_ioa_cfg *) cmd-device-host-hostdata;
spin_lock_irq(cmd-device-host-host_lock);
rc = __ipr_eh_dev_reset(cmd);
[PATCH 2/3] ipr: set coherent DMA mask
From: Anton Blanchard an...@samba.org
Use dma_set_mask_and_coherent() to set both the DMA and coherent
DMA mask.
Signed-off-by: Anton Blanchard an...@samba.org
Signed-off-by: Brian King brk...@linux.vnet.ibm.com
---
drivers/scsi/ipr.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff -puN drivers/scsi/ipr.c~ipr_set_coherent_DMA_mask drivers/scsi/ipr.c
--- scsi-queue/drivers/scsi/ipr.c~ipr_set_coherent_DMA_mask 2014-10-30
17:15:30.007820722 -0500
+++ scsi-queue-bjking1/drivers/scsi/ipr.c 2014-10-30 17:15:30.013820667
-0500
@@ -9621,16 +9621,17 @@ static int ipr_probe_ioa(struct pci_dev
ipr_init_regs(ioa_cfg);
if (ioa_cfg-sis64) {
- rc = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+ rc = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (rc 0) {
- dev_dbg(pdev-dev, Failed to set 64 bit PCI DMA
mask\n);
- rc = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ dev_dbg(pdev-dev, Failed to set 64 bit DMA mask\n);
+ rc = dma_set_mask_and_coherent(pdev-dev,
+ DMA_BIT_MASK(32));
}
} else
- rc = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ rc = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (rc 0) {
- dev_err(pdev-dev, Failed to set PCI DMA mask\n);
+ dev_err(pdev-dev, Failed to set DMA mask\n);
goto cleanup_nomem;
}
_
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv5] clk: ppc-corenet: rename to qoriq and add CLK_OF_DECLARE support
The CLK_OF_DECLARE part is addressed by:
http://patchwork.ozlabs.org/patch/400740/
http://patchwork.ozlabs.org/patch/400741/
http://patchwork.ozlabs.org/patch/400742/
...which does what I was asking earlier, getting rid of the (currently
broken due to a misguided attempt to remove an __init warning) platform
driver part rather than maintaining both approaches.
I suggest sending a rename patch that applies after those patches.
-Scott
On Tue, 2014-10-14 at 05:32 -0500, Lu Jingchang-B35083 wrote:
Hi, Scott and Mike,
Could you please help review this patch. Thanks.
Best Regards,
Jingchang
-Original Message-
From: Jingchang Lu [mailto:jingchang...@freescale.com]
Sent: Friday, October 10, 2014 5:15 PM
To: mturque...@linaro.org
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; linux-
ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Lu
Jingchang-B35083
Subject: [PATCHv5] clk: ppc-corenet: rename to qoriq and add
CLK_OF_DECLARE support
The IP is shared by PPC and ARM, this renames it to qoriq for better
represention, and this also adds the CLK_OF_DECLARE support for being
initialized by of_clk_init() on ARM.
Signed-off-by: Jingchang Lu jingchang...@freescale.com
---
changes in v5:
update drivers/cpufreq/Kconfig.powerpc to slect the renamed config option.
changes in v4:
remove corenet literals omitted in v3 remove.
changes in v3:
generate the patch with -M -C option
changes in v2:
rename the driver name to ppc-qoriq.c for shared on PPC and ARM.
drivers/clk/Kconfig| 10 -
drivers/clk/Makefile | 2 +-
drivers/clk/{clk-ppc-corenet.c = clk-qoriq.c} | 29 +++--
-
drivers/cpufreq/Kconfig.powerpc| 2 +-
4 files changed, 24 insertions(+), 19 deletions(-) rename
drivers/clk/{clk-ppc-corenet.c = clk-qoriq.c} (89%)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index
455fd17..4706a9f 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -101,12 +101,12 @@ config COMMON_CLK_AXI_CLKGEN
Support for the Analog Devices axi-clkgen pcore clock generator
for Xilinx
FPGAs. It is commonly used in Analog Devices' reference designs.
-config CLK_PPC_CORENET
-bool Clock driver for PowerPC corenet platforms
-depends on PPC_E500MC OF
+config CLK_QORIQ
+bool Clock driver for Freescale QorIQ platforms
+depends on (PPC_E500MC || ARM) OF
---help---
- This adds the clock driver support for Freescale PowerPC corenet
- platforms using common clock framework.
+ This adds the clock driver support for Freescale QorIQ platforms
+ using common clock framework.
config COMMON_CLK_XGENE
bool Clock driver for APM XGene SoC
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index
d5fba5b..4ff94cd 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -30,7 +30,7 @@ obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
obj-$(CONFIG_COMMON_CLK_PALMAS) += clk-palmas.o
-obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
+obj-$(CONFIG_CLK_QORIQ) += clk-qoriq.o
obj-$(CONFIG_COMMON_CLK_RK808) += clk-rk808.o
obj-$(CONFIG_COMMON_CLK_S2MPS11)+= clk-s2mps11.o
obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-qoriq.c
similarity index 89% rename from drivers/clk/clk-ppc-corenet.c rename to
drivers/clk/clk-qoriq.c index 8e58edf..48cb923 100644
--- a/drivers/clk/clk-ppc-corenet.c
+++ b/drivers/clk/clk-qoriq.c
@@ -5,7 +5,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
- * clock driver for Freescale PowerPC corenet SoCs.
+ * clock driver for Freescale QorIQ SoCs.
*/
#include linux/clk-provider.h
#include linux/io.h
@@ -155,7 +155,7 @@ static void __init core_pll_init(struct device_node
*np)
base = of_iomap(np, 0);
if (!base) {
-pr_err(clk-ppc: iomap error\n);
+pr_err(clk-qoriq: iomap error\n);
return;
}
@@ -252,7 +252,7 @@ static void __init sysclk_init(struct device_node
*node)
u32 rate;
if (!np) {
-pr_err(ppc-clk: could not get parent node\n);
+pr_err(qoriq-clk: could not get parent node\n);
return;
}
@@ -278,30 +278,35 @@ static const struct of_device_id clk_match[]
__initconst = {
{}
};
-static int __init ppc_corenet_clk_probe(struct platform_device *pdev)
+static int __init qoriq_clk_probe(struct platform_device *pdev)
{
of_clk_init(clk_match);
return 0;
}
-static const struct of_device_id ppc_clk_ids[] __initconst = {
+static const struct of_device_id
Re: [PATCH 1/3] powerpc/dts: Factorize the clock control node
On Thu, 2014-10-30 at 08:58 -0500, Emil Medve wrote:
Hello Scott,
On 10/28/2014 06:21 PM, Scott Wood wrote:
On Wed, 2014-10-22 at 09:42 -0500, Emil Medve wrote:
Signed-off-by: Emil Medve emilian.me...@freescale.com
Change-Id: I25ce24a25862b4ca460164159867abefe00ccdd1
Please remove gerrit stuff prior to submitting.
I did remove the bulk of it. I wanted to keep the Change-Id so I can
easily correlate the upstream patches with the sordid internal history.
Seems the upstream history has enough instances of 'Change-Id' for this
not to be an issue
OK...
I don't think the mux stuff belongs here, given that clockgen2.dtsi
doesn't have it, and I saw at least one clockgen1 user needing to
supplement this with more muxes.
The intent was to put here devices/nodes that are common per chassis
from the low to high end. Specific SoC would change/augment this as
appropriate. I could have put each node in its own file as we've done
elsewhere, but I thought it would be too much
Yes, chassis v1 and v2 have differences, but that's not unexpected
It just strikes me as being an awkward split of where each mux node
goes. Is it guaranteed by the chassis that all v1 will have at least
the first two muxes?
@@ -1068,7 +1043,6 @@
clocks = sysclk;
clock-output-names = pll2, pll2-div2, pll2-div4;
};
-
pll3: pll3@860 {
#clock-cells = 1;
reg = 0x860 0x4;
@@ -1076,7 +1050,6 @@
clocks = sysclk;
clock-output-names = pll3, pll3-div2, pll3-div4;
};
-
pll4: pll4@880 {
#clock-cells = 1;
reg = 0x880 0x4;
Why?
Why what?
Why are you removing all these blank lines?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] powerpc: Remove bootmem allocator
On Thu, 2014-10-30 at 01:00 -0500, Emil Medve wrote: On 09/17/2014 07:15 AM, Anton Blanchard wrote: At the moment we transition from the memblock alloctor to the bootmem allocator. Gitting rid of the bootmem allocator removes a bunch of complicated code (most of which I owe the dubious honour of being responsible for writing). Any idea on how to move these patches forward? It's in my test branch and will go into next on Monday. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: do_notify_resume can be called with bad thread_info flags argument
Back in 7230c5644188 (powerpc: Rework lazy-interrupt handling) we
added a call out to restore_interrupts() (written in c) before calling
do_notify_resume:
bl restore_interrupts
addir3,r1,STACK_FRAME_OVERHEAD
bl do_notify_resume
Unfortunately do_notify_resume takes two arguments, the second one
being the thread_info flags:
void do_notify_resume(struct pt_regs *regs, unsigned long thread_info_flags)
We do populate r4 (the second argument) earlier, but
restore_interrupts() is free to muck it up all it wants. My guess is
the gcc compiler gods shone down on us and its register allocator
never used r4. Sometimes, rarely, luck is on our side.
LLVM on the other hand did trample r4.
To avoid having to reload the flags, pass it through
restore_interrupts, suggested by benh.
Signed-off-by: Anton Blanchard an...@samba.org
Cc: sta...@vger.kernel.org
---
arch/powerpc/kernel/entry_64.S | 6 ++
arch/powerpc/kernel/irq.c | 8 +++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 9caab69..086c566 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -659,7 +659,13 @@ _GLOBAL(ret_from_except_lite)
3:
#endif
bl save_nvgprs
+ /*
+* restore_interrupts takes an argument and returns it unmodified
+* so we can get the thread_info flags into do_notify_resume.
+*/
+ mr r3,r4
bl restore_interrupts
+ mr r4,r3
addir3,r1,STACK_FRAME_OVERHEAD
bl do_notify_resume
b ret_from_except
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 6dbae00..44b0530 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -283,16 +283,22 @@ EXPORT_SYMBOL(arch_local_irq_restore);
* schedule() or do_signal() when returning to userspace. We do it
* in C to avoid the burden of dealing with lockdep etc...
*
+ * We are passed the current thread_info flags which we return. This
+ * is useful in the exception exit code where we already have loaded
+ * the flags and need to use them again after calling restore_interrupts.
+ *
* NOTE: This is called with interrupts hard disabled but not marked
* as such in paca-irq_happened, so we need to resync this.
*/
-void notrace restore_interrupts(void)
+unsigned long notrace restore_interrupts(unsigned long thread_info_flags)
{
if (irqs_disabled()) {
local_paca-irq_happened |= PACA_IRQ_HARD_DIS;
local_irq_enable();
} else
__hard_irq_enable();
+
+ return thread_info_flags;
}
/*
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] powerpc: Remove bootmem allocator
Hello Michael, On 10/30/2014 09:15 PM, Michael Ellerman wrote: On Thu, 2014-10-30 at 01:00 -0500, Emil Medve wrote: On 09/17/2014 07:15 AM, Anton Blanchard wrote: At the moment we transition from the memblock alloctor to the bootmem allocator. Gitting rid of the bootmem allocator removes a bunch of complicated code (most of which I owe the dubious honour of being responsible for writing). Any idea on how to move these patches forward? It's in my test branch and will go into next on Monday. Thank you Cheers, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] powerpc: Don't use local named register variable in current_thread_info
LLVM doesn't support local named register variables and is unlikely
to. current_thread_info is using one, fix it by moving it out and
calling it __current_r1().
I gave it a bit of an obscure name because we don't want anyone else
using it - they should use current_stack_pointer(). This specific
case is performance critical and we can't afford to call a function
to get it. Furthermore it isn't important to know exactly where in
the stack we are since we mask the lower bits.
Signed-off-by: Anton Blanchard an...@samba.org
---
arch/powerpc/include/asm/thread_info.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/thread_info.h
b/arch/powerpc/include/asm/thread_info.h
index b034ecd..ebc4f16 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -71,13 +71,12 @@ struct thread_info {
#define THREAD_SIZE_ORDER (THREAD_SHIFT - PAGE_SHIFT)
/* how to get the thread information struct from C */
+register unsigned long __current_r1 asm(r1);
static inline struct thread_info *current_thread_info(void)
{
- register unsigned long sp asm(r1);
-
/* gcc4, at least, is smart enough to turn this into a single
* rlwinm for ppc32 and clrrdi for ppc64 */
- return (struct thread_info *)(sp ~(THREAD_SIZE-1));
+ return (struct thread_info *)(__current_r1 ~(THREAD_SIZE-1));
}
#endif /* __ASSEMBLY__ */
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] powerpc: Remove double braces in alignment code.
Looks like I introduced this when adding LE support.
Signed-off-by: Anton Blanchard an...@samba.org
---
arch/powerpc/kernel/align.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
index 34f5552..86150fb 100644
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -908,7 +908,7 @@ int fix_alignment(struct pt_regs *regs)
flush_fp_to_thread(current);
}
- if ((nb == 16)) {
+ if (nb == 16) {
if (flags F) {
/* Special case for 16-byte FP loads and stores */
PPC_WARN_ALIGNMENT(fp_pair, regs);
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] powerpc: LLVM complains about forward declaration of struct rtas_sensors
Move the declaration up to silence the warning.
Signed-off-by: Anton Blanchard an...@samba.org
---
arch/powerpc/kernel/rtas-proc.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kernel/rtas-proc.c b/arch/powerpc/kernel/rtas-proc.c
index 8777fb0..fb2fb3e 100644
--- a/arch/powerpc/kernel/rtas-proc.c
+++ b/arch/powerpc/kernel/rtas-proc.c
@@ -113,17 +113,6 @@
#define SENSOR_PREFIX ibm,sensor-
#define cel_to_fahr(x) ((x*9/5)+32)
-
-/* Globals */
-static struct rtas_sensors sensors;
-static struct device_node *rtas_node = NULL;
-static unsigned long power_on_time = 0; /* Save the time the user set */
-static char progress_led[MAX_LINELENGTH];
-
-static unsigned long rtas_tone_frequency = 1000;
-static unsigned long rtas_tone_volume = 0;
-
-/* STRUCTS*** */
struct individual_sensor {
unsigned int token;
unsigned int quant;
@@ -134,6 +123,15 @@ struct rtas_sensors {
unsigned int quant;
};
+/* Globals */
+static struct rtas_sensors sensors;
+static struct device_node *rtas_node = NULL;
+static unsigned long power_on_time = 0; /* Save the time the user set */
+static char progress_led[MAX_LINELENGTH];
+
+static unsigned long rtas_tone_frequency = 1000;
+static unsigned long rtas_tone_volume = 0;
+
/* ** */
/* Declarations */
static int ppc_rtas_sensors_show(struct seq_file *m, void *v);
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/pseries: Quieten ibm,pcie-link-speed-stats warning
The ibm,pcie-link-speed-stats isn't mandatory, so we shouldn't print
a high priority error message when missing. One example where we see
this is QEMU.
Reduce it to pr_info.
Signed-off-by: Anton Blanchard an...@samba.org
---
arch/powerpc/platforms/pseries/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/pci.c
b/arch/powerpc/platforms/pseries/pci.c
index 67e4859..57dd7a0 100644
--- a/arch/powerpc/platforms/pseries/pci.c
+++ b/arch/powerpc/platforms/pseries/pci.c
@@ -134,7 +134,7 @@ int pseries_root_bridge_prepare(struct pci_host_bridge
*bridge)
of_node_put(pdn);
if (rc) {
- pr_err(no ibm,pcie-link-speed-stats property\n);
+ pr_info(no ibm,pcie-link-speed-stats property\n);
return 0;
}
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: do_notify_resume can be called with bad thread_info flags argument
Back in 7230c5644188 (powerpc: Rework lazy-interrupt handling) we added a call out to restore_interrupts() (written in c) before calling do_notify_resume: bl restore_interrupts addir3,r1,STACK_FRAME_OVERHEAD bl do_notify_resume Unfortunately do_notify_resume takes two arguments, the second one being the thread_info flags: void do_notify_resume(struct pt_regs *regs, unsigned long thread_info_flags) We do populate r4 (the second argument) earlier, but restore_interrupts() is free to muck it up all it wants. My guess is the gcc compiler gods shone down on us and its register allocator never used r4. Sometimes, rarely, luck is on our side. LLVM on the other hand did trample r4. Signed-off-by: Anton Blanchard an...@samba.org Cc: sta...@vger.kernel.org --- arch/powerpc/kernel/entry_64.S | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S index 9caab69..194e46d 100644 --- a/arch/powerpc/kernel/entry_64.S +++ b/arch/powerpc/kernel/entry_64.S @@ -659,7 +659,13 @@ _GLOBAL(ret_from_except_lite) 3: #endif bl save_nvgprs + /* +* Use a non volatile GPR to save and restore our thread_info flags +* across the call to restore_interrupts. +*/ + mr r30,r4 bl restore_interrupts + mr r4,r30 addir3,r1,STACK_FRAME_OVERHEAD bl do_notify_resume b ret_from_except -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
