* [PATCH] powerpc: do_notify_resume can be called with bad thread_info flags argument
From: Anton Blanchard @ 2014-10-30 5:12 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev, stable
Back in 7230c5644188 ("powerpc: Rework lazy-interrupt handling") we
added a call out to restore_interrupts() (written in c) before we
call do_notify_resume:
bl restore_interrupts
addi r3,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 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.
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: stable@vger.kernel.org
---
arch/powerpc/kernel/entry_64.S | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 9caab69..add42d0 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -661,6 +661,13 @@ _GLOBAL(ret_from_except_lite)
bl save_nvgprs
bl restore_interrupts
addi r3,r1,STACK_FRAME_OVERHEAD
+ /*
+ * restore_interrupts() is written in c and could clobber all
+ * volatile registers. We need to reload our thread_info flags
+ * in r4 for do_notify_resume().
+ */
+ CURRENT_THREAD_INFO(r9, r1)
+ ld r4,TI_FLAGS(r9)
bl do_notify_resume
b ret_from_except
--
1.9.1
^ permalink raw reply related
* [PATCH] powerpc/powernv: Properly fix LPC debugfs endianness
From: Benjamin Herrenschmidt @ 2014-10-30 5:19 UTC (permalink / raw)
To: linuxppc-dev list
Endian is hard, especially when I designed a stupid FW interface, and
I should know better... oh well, this is attempt #2 at fixing this
properly. This time it seems to work with all access sizes and I
can run my flashing tool (which exercises all sort of access sizes
and types to access the SPI controller in the BMC) just fine.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>
diff --git a/arch/powerpc/platforms/powernv/opal-lpc.c b/arch/powerpc/platforms/powernv/opal-lpc.c
index ad4b31d..af918aa 100644
--- a/arch/powerpc/platforms/powernv/opal-lpc.c
+++ b/arch/powerpc/platforms/powernv/opal-lpc.c
@@ -216,14 +216,54 @@ static ssize_t lpc_debug_read(struct file *filp, char __user *ubuf,
&data, len);
if (rc)
return -ENXIO;
+
+ /*
+ * Now there is some trickery with the data returned by OPAL
+ * as it's the desired data right justified in a 32-bit BE
+ * word.
+ *
+ * This is a very bad interface and I'm to blame for it :-(
+ *
+ * So we can't just apply a 32-bit swap to what comes from OPAL,
+ * because user space expects the *bytes* to be in their proper
+ * respective positions (ie, LPC position).
+ *
+ * So what we really want to do here is to shift data right
+ * appropriately on a LE kernel.
+ *
+ * IE. If the LPC transaction has bytes B0, B1, B2 and B3 in that
+ * order, we have in memory written to by OPAL at the "data"
+ * pointer:
+ *
+ * Bytes: OPAL "data" LE "data"
+ * 32-bit: B0 B1 B2 B3 B0B1B2B3 B3B2B1B0
+ * 16-bit: B0 B1 0000B0B1 B1B00000
+ * 8-bit: B0 000000B0 B0000000
+ *
+ * So a BE kernel will have the leftmost of the above in the MSB
+ * and rightmost in the LSB and can just then "cast" the u32 "data"
+ * down to the appropriate quantity and write it.
+ *
+ * However, an LE kernel can't. It doesn't need to swap because a
+ * load from data followed by a store to user are going to preserve
+ * the byte ordering which is the wire byte order which is what the
+ * user wants, but in order to "crop" to the right size, we need to
+ * shift right first.
+ */
switch(len) {
case 4:
rc = __put_user((u32)data, (u32 __user *)ubuf);
break;
case 2:
+#ifdef __LITTLE_ENDIAN__
+ data >>= 16;
+#endif
rc = __put_user((u16)data, (u16 __user *)ubuf);
break;
default:
+#ifdef __LITTLE_ENDIAN__
+ data >>= 24;
+#endif
rc = __put_user((u8)data, (u8 __user *)ubuf);
break;
}
@@ -263,12 +303,31 @@ static ssize_t lpc_debug_write(struct file *filp, const char __user *ubuf,
else if (todo > 1 && (pos & 1) == 0)
len = 2;
}
+
+ /*
+ * Similarly to the read case, we have some trickery here but
+ * it's different to handle. We need to pass the value to OPAL in
+ * a register whose layout depends on the access size. We want
+ * to reproduce the memory layout of the user, however we aren't
+ * doing a load from user and a store to another memory location
+ * which would achieve that. Here we pass the value to OPAL via
+ * a register which is expected to contain the "BE" interpretation
+ * of the byte sequence. IE: for a 32-bit access, byte 0 should be
+ * in the MSB. So here we *do* need to byteswap on LE.
+ *
+ * User bytes: LE "data" OPAL "data"
+ * 32-bit: B0 B1 B2 B3 B3B2B1B0 B0B1B2B3
+ * 16-bit: B0 B1 0000B1B0 0000B0B1
+ * 8-bit: B0 000000B0 000000B0
+ */
switch(len) {
case 4:
rc = __get_user(data, (u32 __user *)ubuf);
+ data = cpu_to_be32(data);
break;
case 2:
rc = __get_user(data, (u16 __user *)ubuf);
+ data = cpu_to_be16(data);
break;
default:
rc = __get_user(data, (u8 __user *)ubuf);
^ permalink raw reply related
* Re: [PATCH 1/5] powerpc: Remove bootmem allocator
From: Emil Medve @ 2014-10-30 6:00 UTC (permalink / raw)
To: Anton Blanchard, benh, paulus, mpe; +Cc: linuxppc-dev
In-Reply-To: <1410956137-4824-1-git-send-email-anton@samba.org>
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 <anton@samba.org>
> Tested-by: Emil Medve <Emilian.Medve@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,
^ permalink raw reply
* [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
From: Denis Kirjanov @ 2014-10-30 6:12 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, Denis Kirjanov, Alexei Starovoitov, Matt Evans
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 Starovoitov<alexei.starovoitov@gmail.com>
CC: Michael Ellerman<mpe@ellerman.id.au>
Cc: Matt Evans <matt@ozlabs.org>
Signed-off-by: Denis Kirjanov <kda@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_DOT 0x7c000127
/* Misc instructions for BPF compiler */
+#define PPC_INST_LBZ 0x88000000
#define PPC_INST_LD 0xe8000000
#define PPC_INST_LHZ 0xa0000000
#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
^ permalink raw reply related
* Re: FSL MSI Mapping
From: Johannes Thumshirn @ 2014-10-30 6:58 UTC (permalink / raw)
To: Michael Ellerman
Cc: Johannes Thumshirn, Sebastian Andrzej Siewior, linuxppc-dev,
'David Engster'
In-Reply-To: <1414641117.12600.4.camel@concordia>
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.
^ permalink raw reply
* [PATCH v3 1/3] QE: move qe code from arch/powerpc to drivers/soc
From: Zhao Qiang @ 2014-10-30 7:31 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, B07421; +Cc: Zhao Qiang, R63061
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 <B45475@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>
-#include <asm/qe.h>
-#include <asm/qe_ic.h>
+#include <linux/fsl/qe.h>
+#include <linux/fsl/qe_ic.h>
#include "mpc83xx.h"
diff --git a/arch/powerpc/platforms/83xx/misc.c b/arch/powerpc/platforms/83xx/misc.c
index 125336f..3e2e6d2 100644
--- a/arch/powerpc/platforms/83xx/misc.c
+++ b/arch/powerpc/platforms/83xx/misc.c
@@ -17,7 +17,7 @@
#include <asm/io.h>
#include <asm/hw_irq.h>
#include <asm/ipic.h>
-#include <asm/qe_ic.h>
+#include <linux/fsl/qe_ic.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index 8d76220..e1186be 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -36,8 +36,8 @@
#include <asm/udbg.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
-#include <asm/qe.h>
-#include <asm/qe_ic.h>
+#include <linux/fsl/qe.h>
+#include <linux/fsl/qe_ic.h>
#include "mpc83xx.h"
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index eff5baa..9f75944 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -25,8 +25,8 @@
#include <asm/time.h>
#include <asm/ipic.h>
#include <asm/udbg.h>
-#include <asm/qe.h>
-#include <asm/qe_ic.h>
+#include <linux/fsl/qe.h>
+#include <linux/fsl/qe_ic.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 1a26d2f..7c1a22f 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -44,8 +44,8 @@
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
#include <sysdev/simple_gpio.h>
-#include <asm/qe.h>
-#include <asm/qe_ic.h>
+#include <linux/fsl/qe.h>
+#include <linux/fsl/qe_ic.h>
#include "mpc83xx.h"
diff --git a/arch/powerpc/platforms/83xx/mpc836x_rdk.c b/arch/powerpc/platforms/83xx/mpc836x_rdk.c
index b63b42d..5e17d71 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_rdk.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_rdk.c
@@ -20,8 +20,8 @@
#include <asm/time.h>
#include <asm/ipic.h>
#include <asm/udbg.h>
-#include <asm/qe.h>
-#include <asm/qe_ic.h>
+#include <linux/fsl/qe.h>
+#include <linux/fsl/qe_ic.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
diff --git a/arch/powerpc/platforms/85xx/common.c b/arch/powerpc/platforms/85xx/common.c
index b564b5e..dfb21da 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -9,7 +9,7 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
-#include <asm/qe.h>
+#include <linux/fsl/qe.h>
#include <sysdev/cpm2_pic.h>
#include "mpc85xx.h"
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index e56b89a..5e2acb9 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -27,7 +27,7 @@
#include <asm/udbg.h>
#include <asm/mpic.h>
#include <asm/ehv_pic.h>
-#include <asm/qe_ic.h>
+#include <linux/fsl/qe_ic.h>
#include <linux/of_platform.h>
#include <sysdev/fsl_soc.h>
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index a392e94..7cf8eb5 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -47,8 +47,8 @@
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
#include <sysdev/simple_gpio.h>
-#include <asm/qe.h>
-#include <asm/qe_ic.h>
+#include <linux/fsl/qe.h>
+#include <linux/fsl/qe_ic.h>
#include <asm/mpic.h>
#include <asm/swiotlb.h>
#include <asm/fsl_guts.h>
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index e358bed..d1b6d1b 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -25,8 +25,8 @@
#include <asm/prom.h>
#include <asm/udbg.h>
#include <asm/mpic.h>
-#include <asm/qe.h>
-#include <asm/qe_ic.h>
+#include <linux/fsl/qe.h>
+#include <linux/fsl/qe_ic.h>
#include <asm/fsl_guts.h>
#include <sysdev/fsl_soc.h>
diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c b/arch/powerpc/platforms/85xx/twr_p102x.c
index 1eadb6d..7df08d9 100644
--- a/arch/powerpc/platforms/85xx/twr_p102x.c
+++ b/arch/powerpc/platforms/85xx/twr_p102x.c
@@ -21,8 +21,8 @@
#include <asm/pci-bridge.h>
#include <asm/udbg.h>
#include <asm/mpic.h>
-#include <asm/qe.h>
-#include <asm/qe_ic.h>
+#include <linux/fsl/qe.h>
+#include <linux/fsl/qe_ic.h>
#include <asm/fsl_guts.h>
#include <sysdev/fsl_soc.h>
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 391b3f6..ae8879c 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -277,25 +277,6 @@ config TAU_AVERAGE
If in doubt, say N here.
-config QUICC_ENGINE
- bool "Freescale QUICC Engine (QE) Support"
- depends on FSL_SOC && PPC32
- select PPC_LIB_RHEAP
- select CRC32
- help
- The QUICC Engine (QE) is a new generation of communications
- coprocessors on Freescale embedded CPUs (akin to CPM in older chips).
- Selecting this option means that you wish to build a kernel
- for a machine with a QE coprocessor.
-
-config QE_GPIO
- bool "QE GPIO support"
- depends on QUICC_ENGINE
- select ARCH_REQUIRE_GPIOLIB
- help
- Say Y here if you're going to use hardware that connects to the
- QE GPIOs.
-
config CPM2
bool "Enable support for the CPM2 (Communications Processor Module)"
depends on (FSL_SOC_BOOKE && PPC32) || 8260
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index f7cb2a1..087d301 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -26,7 +26,6 @@ obj-$(CONFIG_FSL_85XX_CACHE_SRAM) += fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o
obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o
obj-$(CONFIG_FSL_RIO) += fsl_rio.o fsl_rmu.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
-obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o mv64x60_dev.o \
mv64x60_udbg.o
diff --git a/arch/powerpc/sysdev/qe_lib/Kconfig b/arch/powerpc/sysdev/qe_lib/Kconfig
deleted file mode 100644
index 3c25199..0000000
--- a/arch/powerpc/sysdev/qe_lib/Kconfig
+++ /dev/null
@@ -1,27 +0,0 @@
-#
-# QE Communication options
-#
-
-config UCC_SLOW
- bool
- default y if SERIAL_QE
- help
- This option provides qe_lib support to UCC slow
- protocols: UART, BISYNC, QMC
-
-config UCC_FAST
- bool
- default y if UCC_GETH
- help
- This option provides qe_lib support to UCC fast
- protocols: HDLC, Ethernet, ATM, transparent
-
-config UCC
- bool
- default y if UCC_FAST || UCC_SLOW
-
-config QE_USB
- bool
- default y if USB_FSL_QE
- help
- QE USB Controller support
diff --git a/drivers/net/ethernet/freescale/fsl_pq_mdio.c b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
index 583e71a..958353c 100644
--- a/drivers/net/ethernet/freescale/fsl_pq_mdio.c
+++ b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
@@ -28,7 +28,7 @@
#include <linux/of_device.h>
#include <asm/io.h>
-#include <asm/ucc.h> /* for ucc_set_qe_mux_mii_mng() */
+#include <linux/fsl/ucc.h> /* for ucc_set_qe_mux_mii_mng() */
#include "gianfar.h"
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index fab39e2..ef7740c 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -40,10 +40,10 @@
#include <asm/uaccess.h>
#include <asm/irq.h>
#include <asm/io.h>
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
-#include <asm/ucc.h>
-#include <asm/ucc_fast.h>
+#include <linux/fsl/immap_qe.h>
+#include <linux/fsl/qe.h>
+#include <linux/fsl/ucc.h>
+#include <linux/fsl/ucc_fast.h>
#include <asm/machdep.h>
#include "ucc_geth.h"
diff --git a/drivers/net/ethernet/freescale/ucc_geth.h b/drivers/net/ethernet/freescale/ucc_geth.h
index 75f3371..a803635 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.h
+++ b/drivers/net/ethernet/freescale/ucc_geth.h
@@ -22,11 +22,11 @@
#include <linux/list.h>
#include <linux/if_ether.h>
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
+#include <linux/fsl/immap_qe.h>
+#include <linux/fsl/qe.h>
-#include <asm/ucc.h>
-#include <asm/ucc_fast.h>
+#include <linux/fsl/ucc.h>
+#include <linux/fsl/ucc_fast.h>
#define DRV_DESC "QE UCC Gigabit Ethernet Controller"
#define DRV_NAME "ucc_geth"
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index c854385..5c8f982 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,4 +2,6 @@ menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/fsl-qe/Kconfig"
+
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 0f7c447..4ebd131 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_ARCH_QCOM) += qcom/
+obj-$(CONFIG_QUICC_ENGINE) += fsl-qe/
diff --git a/drivers/soc/fsl-qe/Kconfig b/drivers/soc/fsl-qe/Kconfig
new file mode 100644
index 0000000..8b03ca2
--- /dev/null
+++ b/drivers/soc/fsl-qe/Kconfig
@@ -0,0 +1,45 @@
+#
+# QE Communication options
+#
+config QUICC_ENGINE
+ bool "Freescale QUICC Engine (QE) Support"
+ depends on FSL_SOC && PPC32
+ select PPC_LIB_RHEAP
+ select CRC32
+ help
+ The QUICC Engine (QE) is a new generation of communications
+ coprocessors on Freescale embedded CPUs (akin to CPM in older chips).
+ Selecting this option means that you wish to build a kernel
+ for a machine with a QE coprocessor.
+
+config QE_GPIO
+ bool "QE GPIO support"
+ depends on QUICC_ENGINE
+ select ARCH_REQUIRE_GPIOLIB
+ help
+ Say Y here if you're going to use hardware that connects to the
+ QE GPIOs.
+
+config UCC_SLOW
+ bool
+ default y if SERIAL_QE
+ help
+ This option provides qe_lib support to UCC slow
+ protocols: UART, BISYNC, QMC
+
+config UCC_FAST
+ bool
+ default y if UCC_GETH
+ help
+ This option provides qe_lib support to UCC fast
+ protocols: HDLC, Ethernet, ATM, transparent
+
+config UCC
+ bool
+ default y if UCC_FAST || UCC_SLOW
+
+config QE_USB
+ bool
+ default y if USB_FSL_QE
+ help
+ QE USB Controller support
diff --git a/arch/powerpc/sysdev/qe_lib/Makefile b/drivers/soc/fsl-qe/Makefile
similarity index 100%
rename from arch/powerpc/sysdev/qe_lib/Makefile
rename to drivers/soc/fsl-qe/Makefile
diff --git a/arch/powerpc/sysdev/qe_lib/gpio.c b/drivers/soc/fsl-qe/gpio.c
similarity index 99%
rename from arch/powerpc/sysdev/qe_lib/gpio.c
rename to drivers/soc/fsl-qe/gpio.c
index 521e67a..1e38588 100644
--- a/arch/powerpc/sysdev/qe_lib/gpio.c
+++ b/drivers/soc/fsl-qe/gpio.c
@@ -21,7 +21,7 @@
#include <linux/gpio.h>
#include <linux/slab.h>
#include <linux/export.h>
-#include <asm/qe.h>
+#include <linux/fsl/qe.h>
struct qe_gpio_chip {
struct of_mm_gpio_chip mm_gc;
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/drivers/soc/fsl-qe/qe.c
similarity index 99%
rename from arch/powerpc/sysdev/qe_lib/qe.c
rename to drivers/soc/fsl-qe/qe.c
index 238a07b..1c5beef 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/drivers/soc/fsl-qe/qe.c
@@ -32,8 +32,8 @@
#include <asm/irq.h>
#include <asm/page.h>
#include <asm/pgtable.h>
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
+#include <linux/fsl/immap_qe.h>
+#include <linux/fsl/qe.h>
#include <asm/prom.h>
#include <asm/rheap.h>
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/drivers/soc/fsl-qe/qe_ic.c
similarity index 99%
rename from arch/powerpc/sysdev/qe_lib/qe_ic.c
rename to drivers/soc/fsl-qe/qe_ic.c
index b2b87c3..eb4d160 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/drivers/soc/fsl-qe/qe_ic.c
@@ -28,7 +28,7 @@
#include <asm/irq.h>
#include <asm/io.h>
#include <asm/prom.h>
-#include <asm/qe_ic.h>
+#include <linux/fsl/qe_ic.h>
#include "qe_ic.h"
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.h b/drivers/soc/fsl-qe/qe_ic.h
similarity index 98%
rename from arch/powerpc/sysdev/qe_lib/qe_ic.h
rename to drivers/soc/fsl-qe/qe_ic.h
index efef7ab..5c4480e 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.h
+++ b/drivers/soc/fsl-qe/qe_ic.h
@@ -16,7 +16,7 @@
#ifndef _POWERPC_SYSDEV_QE_IC_H
#define _POWERPC_SYSDEV_QE_IC_H
-#include <asm/qe_ic.h>
+#include <linux/fsl/qe_ic.h>
#define NR_QE_IC_INTS 64
diff --git a/arch/powerpc/sysdev/qe_lib/qe_io.c b/drivers/soc/fsl-qe/qe_io.c
similarity index 99%
rename from arch/powerpc/sysdev/qe_lib/qe_io.c
rename to drivers/soc/fsl-qe/qe_io.c
index d099941..3bdc2c7 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_io.c
+++ b/drivers/soc/fsl-qe/qe_io.c
@@ -21,7 +21,7 @@
#include <linux/ioport.h>
#include <asm/io.h>
-#include <asm/qe.h>
+#include <linux/fsl/qe.h>
#include <asm/prom.h>
#include <sysdev/fsl_soc.h>
diff --git a/arch/powerpc/sysdev/qe_lib/ucc.c b/drivers/soc/fsl-qe/ucc.c
similarity index 98%
rename from arch/powerpc/sysdev/qe_lib/ucc.c
rename to drivers/soc/fsl-qe/ucc.c
index 621575b..36a206f 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc.c
+++ b/drivers/soc/fsl-qe/ucc.c
@@ -21,9 +21,9 @@
#include <asm/irq.h>
#include <asm/io.h>
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
-#include <asm/ucc.h>
+#include <linux/fsl/immap_qe.h>
+#include <linux/fsl/qe.h>
+#include <linux/fsl/ucc.h>
int ucc_set_qe_mux_mii_mng(unsigned int ucc_num)
{
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c b/drivers/soc/fsl-qe/ucc_fast.c
similarity index 98%
rename from arch/powerpc/sysdev/qe_lib/ucc_fast.c
rename to drivers/soc/fsl-qe/ucc_fast.c
index 65aaf15..223bb36 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/drivers/soc/fsl-qe/ucc_fast.c
@@ -21,11 +21,11 @@
#include <linux/export.h>
#include <asm/io.h>
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
+#include <linux/fsl/immap_qe.h>
+#include <linux/fsl/qe.h>
-#include <asm/ucc.h>
-#include <asm/ucc_fast.h>
+#include <linux/fsl/ucc.h>
+#include <linux/fsl/ucc_fast.h>
void ucc_fast_dump_regs(struct ucc_fast_private * uccf)
{
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_slow.c b/drivers/soc/fsl-qe/ucc_slow.c
similarity index 98%
rename from arch/powerpc/sysdev/qe_lib/ucc_slow.c
rename to drivers/soc/fsl-qe/ucc_slow.c
index befaf11..7dfff79 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_slow.c
+++ b/drivers/soc/fsl-qe/ucc_slow.c
@@ -21,11 +21,11 @@
#include <linux/export.h>
#include <asm/io.h>
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
+#include <linux/fsl/immap_qe.h>
+#include <linux/fsl/qe.h>
-#include <asm/ucc.h>
-#include <asm/ucc_slow.h>
+#include <linux/fsl/ucc.h>
+#include <linux/fsl/ucc_slow.h>
u32 ucc_slow_get_qe_cr_subblock(int uccs_num)
{
diff --git a/arch/powerpc/sysdev/qe_lib/usb.c b/drivers/soc/fsl-qe/usb.c
similarity index 96%
rename from arch/powerpc/sysdev/qe_lib/usb.c
rename to drivers/soc/fsl-qe/usb.c
index 27f23bd..0bcdf7d 100644
--- a/arch/powerpc/sysdev/qe_lib/usb.c
+++ b/drivers/soc/fsl-qe/usb.c
@@ -17,8 +17,8 @@
#include <linux/errno.h>
#include <linux/export.h>
#include <linux/io.h>
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
+#include <linux/fsl/immap_qe.h>
+#include <linux/fsl/qe.h>
int qe_usb_clock_set(enum qe_clock clk, int rate)
{
diff --git a/drivers/spi/spi-fsl-cpm.c b/drivers/spi/spi-fsl-cpm.c
index 54b0637..b23676f 100644
--- a/drivers/spi/spi-fsl-cpm.c
+++ b/drivers/spi/spi-fsl-cpm.c
@@ -22,7 +22,7 @@
#include <linux/dma-mapping.h>
#include <linux/of_address.h>
#include <asm/cpm.h>
-#include <asm/qe.h>
+#include <linux/fsl/qe.h>
#include "spi-fsl-lib.h"
#include "spi-fsl-cpm.h"
diff --git a/drivers/tty/serial/ucc_uart.c b/drivers/tty/serial/ucc_uart.c
index d569ca5..493f74e 100644
--- a/drivers/tty/serial/ucc_uart.c
+++ b/drivers/tty/serial/ucc_uart.c
@@ -31,7 +31,7 @@
#include <linux/dma-mapping.h>
#include <linux/fs_uart_pd.h>
-#include <asm/ucc_slow.h>
+#include <linux/fsl/ucc_slow.h>
#include <linux/firmware.h>
#include <asm/reg.h>
diff --git a/drivers/usb/gadget/fsl_qe_udc.c b/drivers/usb/gadget/fsl_qe_udc.c
index ad54833..a1d4e00 100644
--- a/drivers/usb/gadget/fsl_qe_udc.c
+++ b/drivers/usb/gadget/fsl_qe_udc.c
@@ -38,7 +38,7 @@
#include <linux/usb/ch9.h>
#include <linux/usb/gadget.h>
#include <linux/usb/otg.h>
-#include <asm/qe.h>
+#include <linux/fsl/qe.h>
#include <asm/cpm.h>
#include <asm/dma.h>
#include <asm/reg.h>
diff --git a/drivers/usb/host/fhci-hcd.c b/drivers/usb/host/fhci-hcd.c
index 1cf68ea..7df4e74 100644
--- a/drivers/usb/host/fhci-hcd.c
+++ b/drivers/usb/host/fhci-hcd.c
@@ -31,7 +31,7 @@
#include <linux/of_platform.h>
#include <linux/of_gpio.h>
#include <linux/slab.h>
-#include <asm/qe.h>
+#include <linux/fsl/qe.h>
#include <asm/fsl_gtm.h>
#include "fhci.h"
diff --git a/drivers/usb/host/fhci-hub.c b/drivers/usb/host/fhci-hub.c
index 6af2512..31b4402 100644
--- a/drivers/usb/host/fhci-hub.c
+++ b/drivers/usb/host/fhci-hub.c
@@ -24,7 +24,7 @@
#include <linux/usb.h>
#include <linux/usb/hcd.h>
#include <linux/gpio.h>
-#include <asm/qe.h>
+#include <linux/fsl/qe.h>
#include "fhci.h"
/* virtual root hub specific descriptor */
diff --git a/drivers/usb/host/fhci-sched.c b/drivers/usb/host/fhci-sched.c
index 95ca598..6f1d4ad 100644
--- a/drivers/usb/host/fhci-sched.c
+++ b/drivers/usb/host/fhci-sched.c
@@ -25,7 +25,7 @@
#include <linux/io.h>
#include <linux/usb.h>
#include <linux/usb/hcd.h>
-#include <asm/qe.h>
+#include <linux/fsl/qe.h>
#include <asm/fsl_gtm.h>
#include "fhci.h"
diff --git a/drivers/usb/host/fhci.h b/drivers/usb/host/fhci.h
index 154e6a0..d7c49531 100644
--- a/drivers/usb/host/fhci.h
+++ b/drivers/usb/host/fhci.h
@@ -27,8 +27,8 @@
#include <linux/io.h>
#include <linux/usb.h>
#include <linux/usb/hcd.h>
-#include <asm/qe.h>
-#include <asm/immap_qe.h>
+#include <linux/fsl/qe.h>
+#include <linux/fsl/immap_qe.h>
#define USB_CLOCK 48000000
diff --git a/arch/powerpc/include/asm/immap_qe.h b/include/linux/fsl/immap_qe.h
similarity index 100%
rename from arch/powerpc/include/asm/immap_qe.h
rename to include/linux/fsl/immap_qe.h
diff --git a/arch/powerpc/include/asm/qe.h b/include/linux/fsl/qe.h
similarity index 99%
rename from arch/powerpc/include/asm/qe.h
rename to include/linux/fsl/qe.h
index 32b9bfa..1c9d626 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/include/linux/fsl/qe.h
@@ -20,7 +20,7 @@
#include <linux/errno.h>
#include <linux/err.h>
#include <asm/cpm.h>
-#include <asm/immap_qe.h>
+#include <linux/fsl/immap_qe.h>
#define QE_NUM_OF_SNUM 256 /* There are 256 serial number in QE */
#define QE_NUM_OF_BRGS 16
diff --git a/arch/powerpc/include/asm/qe_ic.h b/include/linux/fsl/qe_ic.h
similarity index 100%
rename from arch/powerpc/include/asm/qe_ic.h
rename to include/linux/fsl/qe_ic.h
diff --git a/arch/powerpc/include/asm/ucc.h b/include/linux/fsl/ucc.h
similarity index 96%
rename from arch/powerpc/include/asm/ucc.h
rename to include/linux/fsl/ucc.h
index 6927ac2..d448813 100644
--- a/arch/powerpc/include/asm/ucc.h
+++ b/include/linux/fsl/ucc.h
@@ -15,8 +15,8 @@
#ifndef __UCC_H__
#define __UCC_H__
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
+#include <linux/fsl/immap_qe.h>
+#include <linux/fsl/qe.h>
#define STATISTICS
diff --git a/arch/powerpc/include/asm/ucc_fast.h b/include/linux/fsl/ucc_fast.h
similarity index 98%
rename from arch/powerpc/include/asm/ucc_fast.h
rename to include/linux/fsl/ucc_fast.h
index 72ea9ba..101fae7 100644
--- a/arch/powerpc/include/asm/ucc_fast.h
+++ b/include/linux/fsl/ucc_fast.h
@@ -16,10 +16,10 @@
#include <linux/kernel.h>
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
+#include <linux/fsl/immap_qe.h>
+#include <linux/fsl/qe.h>
-#include <asm/ucc.h>
+#include <linux/fsl/ucc.h>
/* Receive BD's status */
#define R_E 0x80000000 /* buffer empty */
diff --git a/arch/powerpc/include/asm/ucc_slow.h b/include/linux/fsl/ucc_slow.h
similarity index 99%
rename from arch/powerpc/include/asm/ucc_slow.h
rename to include/linux/fsl/ucc_slow.h
index c44131e..61f4c83 100644
--- a/arch/powerpc/include/asm/ucc_slow.h
+++ b/include/linux/fsl/ucc_slow.h
@@ -17,10 +17,10 @@
#include <linux/kernel.h>
-#include <asm/immap_qe.h>
-#include <asm/qe.h>
+#include <linux/fsl/immap_qe.h>
+#include <linux/fsl/qe.h>
-#include <asm/ucc.h>
+#include <linux/fsl/ucc.h>
/* transmit BD's status */
#define T_R 0x80000000 /* ready bit */
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH v3 2/3] qe_common: add qe common functions into qe_common.c
From: Zhao Qiang @ 2014-10-30 7:31 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, B07421; +Cc: Zhao Qiang, R63061
In-Reply-To: <1414654264-2596-1-git-send-email-B45475@freescale.com>
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 <B45475@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 0000000..c82ddcc
--- /dev/null
+++ b/drivers/soc/fsl-qe/qe_common.c
@@ -0,0 +1,185 @@
+/*
+ * Common QE code
+ *
+ * Author: Scott Wood <scottwood@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 (dmalek@jlc.net)
+ * Copyright (c) 1999-2001 Dan Malek <dan@embeddedalley.com>
+ * Copyright (c) 2000 MontaVista Software, Inc (source@mvista.com)
+ * 2006 (c) MontaVista Software, Inc.
+ * Vitaly Bordug <vbordug@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);
+ spin_unlock_irqrestore(&qe_muram_lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL(qe_muram_free);
+
+/**
+ * qe_muram_alloc_fixed - reserve a specific region of multi-user ram
+ * @offset: the offset into the muram area to reserve
+ * @size: the number of bytes to reserve
+ *
+ * This function returns "start" on success, -ENOMEM on failure.
+ * 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_fixed(unsigned long offset, unsigned long size)
+{
+ unsigned long start;
+ unsigned long flags;
+
+ spin_lock_irqsave(&qe_muram_lock, flags);
+ qe_muram_info.alignment = 1;
+ start = rh_alloc_fixed(&qe_muram_info, offset, size, "commproc");
+ spin_unlock_irqrestore(&qe_muram_lock, flags);
+
+ return start;
+}
+EXPORT_SYMBOL(qe_muram_alloc_fixed);
+
+/**
+ * qe_muram_addr - turn a muram offset into a virtual address
+ * @offset: muram offset to convert
+ */
+void __iomem *qe_muram_addr(unsigned long offset)
+{
+ return muram_vbase + offset;
+}
+EXPORT_SYMBOL(qe_muram_addr);
+
+unsigned long qe_muram_offset(void __iomem *addr)
+{
+ return addr - (void __iomem *)muram_vbase;
+}
+EXPORT_SYMBOL(qe_muram_offset);
+
+/**
+ * qe_muram_dma - turn a muram virtual address into a DMA address
+ * @offset: virtual address from qe_muram_addr() to convert
+ */
+dma_addr_t qe_muram_dma(void __iomem *addr)
+{
+ return muram_pbase + ((u8 __iomem *)addr - muram_vbase);
+}
+EXPORT_SYMBOL(qe_muram_dma);
diff --git a/include/linux/fsl/qe.h b/include/linux/fsl/qe.h
index 1c9d626..8ac5a8c 100644
--- a/include/linux/fsl/qe.h
+++ b/include/linux/fsl/qe.h
@@ -19,7 +19,8 @@
#include <linux/spinlock.h>
#include <linux/errno.h>
#include <linux/err.h>
-#include <asm/cpm.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/fsl/immap_qe.h>
#define QE_NUM_OF_SNUM 256 /* There are 256 serial number in QE */
@@ -186,13 +187,48 @@ static inline int qe_alive_during_sleep(void)
#endif
}
-/* we actually use cpm_muram implementation, define this for convenience */
-#define qe_muram_init cpm_muram_init
-#define qe_muram_alloc cpm_muram_alloc
-#define qe_muram_alloc_fixed cpm_muram_alloc_fixed
-#define qe_muram_free cpm_muram_free
-#define qe_muram_addr cpm_muram_addr
-#define qe_muram_offset cpm_muram_offset
+int qe_muram_init(void);
+
+#if defined(CONFIG_QUICC_ENGINE)
+unsigned long qe_muram_alloc(unsigned long size, unsigned long align);
+int qe_muram_free(unsigned long offset);
+unsigned long qe_muram_alloc_fixed(unsigned long offset, unsigned long size);
+void __iomem *qe_muram_addr(unsigned long offset);
+unsigned long qe_muram_offset(void __iomem *addr);
+dma_addr_t qe_muram_dma(void __iomem *addr);
+#else
+static inline unsigned long qe_muram_alloc(unsigned long size,
+ unsigned long align)
+{
+ return -ENOSYS;
+}
+
+static inline int qe_muram_free(unsigned long offset)
+{
+ return -ENOSYS;
+}
+
+static inline unsigned long qe_muram_alloc_fixed(unsigned long offset,
+ unsigned long size)
+{
+ return -ENOSYS;
+}
+
+static inline void __iomem *qe_muram_addr(unsigned long offset)
+{
+ return NULL;
+}
+
+static inline unsigned long qe_muram_offset(void __iomem *addr)
+{
+ return -ENOSYS;
+}
+
+static inline dma_addr_t qe_muram_dma(void __iomem *addr)
+{
+ return 0;
+}
+#endif /* defined(CONFIG_QUICC_ENGINE) */
/* Structure that defines QE firmware binary files.
*
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH v3 3/3] rheap: move rheap.c from arch/powerpc/lib/ to lib/
From: Zhao Qiang @ 2014-10-30 7:31 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, B07421; +Cc: Zhao Qiang, R63061
In-Reply-To: <1414654264-2596-1-git-send-email-B45475@freescale.com>
qe need to use the rheap, so move it to public directory.
Signed-off-by: Zhao Qiang <B45475@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 a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c
index 8dc1e24..5a63d35 100644
--- a/arch/powerpc/sysdev/cpm2.c
+++ b/arch/powerpc/sysdev/cpm2.c
@@ -41,7 +41,7 @@
#include <asm/page.h>
#include <asm/pgtable.h>
#include <asm/cpm2.h>
-#include <asm/rheap.h>
+#include <linux/fsl/rheap.h>
#include <asm/fs_pd.h>
#include <sysdev/fsl_soc.h>
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index 4f78695..3e06505 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -27,7 +27,7 @@
#include <asm/udbg.h>
#include <asm/io.h>
-#include <asm/rheap.h>
+#include <linux/fsl/rheap.h>
#include <asm/cpm.h>
#include <mm/mmu_decl.h>
diff --git a/arch/powerpc/sysdev/ppc4xx_ocm.c b/arch/powerpc/sysdev/ppc4xx_ocm.c
index 85d9e37..cfe2e19 100644
--- a/arch/powerpc/sysdev/ppc4xx_ocm.c
+++ b/arch/powerpc/sysdev/ppc4xx_ocm.c
@@ -27,7 +27,7 @@
#include <linux/dma-mapping.h>
#include <linux/of.h>
#include <linux/of_address.h>
-#include <asm/rheap.h>
+#include <linux/fsl/rheap.h>
#include <asm/ppc4xx_ocm.h>
#include <linux/slab.h>
#include <linux/debugfs.h>
diff --git a/drivers/dma/bestcomm/Kconfig b/drivers/dma/bestcomm/Kconfig
index 29e4270..9bb1bf8 100644
--- a/drivers/dma/bestcomm/Kconfig
+++ b/drivers/dma/bestcomm/Kconfig
@@ -6,7 +6,7 @@ config PPC_BESTCOMM
tristate "Bestcomm DMA engine support"
depends on PPC_MPC52xx
default n
- select PPC_LIB_RHEAP
+ select LIB_RHEAP
help
BestComm is the name of the communication coprocessor found
on the Freescale MPC5200 family of processor. Its usage is
diff --git a/drivers/soc/fsl-qe/Kconfig b/drivers/soc/fsl-qe/Kconfig
index 8b03ca2..6241819 100644
--- a/drivers/soc/fsl-qe/Kconfig
+++ b/drivers/soc/fsl-qe/Kconfig
@@ -4,7 +4,7 @@
config QUICC_ENGINE
bool "Freescale QUICC Engine (QE) Support"
depends on FSL_SOC && PPC32
- select PPC_LIB_RHEAP
+ select LIB_RHEAP
select CRC32
help
The QUICC Engine (QE) is a new generation of communications
diff --git a/drivers/soc/fsl-qe/qe.c b/drivers/soc/fsl-qe/qe.c
index 1c5beef..504bbd6 100644
--- a/drivers/soc/fsl-qe/qe.c
+++ b/drivers/soc/fsl-qe/qe.c
@@ -35,7 +35,7 @@
#include <linux/fsl/immap_qe.h>
#include <linux/fsl/qe.h>
#include <asm/prom.h>
-#include <asm/rheap.h>
+#include <linux/fsl/rheap.h>
static void qe_snums_init(void);
static int qe_sdma_init(void);
diff --git a/drivers/soc/fsl-qe/qe_common.c b/drivers/soc/fsl-qe/qe_common.c
index c82ddcc..e7fdd02 100644
--- a/drivers/soc/fsl-qe/qe_common.c
+++ b/drivers/soc/fsl-qe/qe_common.c
@@ -26,7 +26,7 @@
#include <linux/slab.h>
#include <linux/io.h>
-#include <asm/rheap.h>
+#include <linux/fsl/rheap.h>
#include <linux/fsl/qe.h>
static spinlock_t qe_muram_lock;
diff --git a/include/linux/fsl/bestcomm/sram.h b/include/linux/fsl/bestcomm/sram.h
index b6d6689..117eaa1 100644
--- a/include/linux/fsl/bestcomm/sram.h
+++ b/include/linux/fsl/bestcomm/sram.h
@@ -12,7 +12,7 @@
#ifndef __BESTCOMM_SRAM_H__
#define __BESTCOMM_SRAM_H__
-#include <asm/rheap.h>
+#include <linux/fsl/rheap.h>
#include <asm/mmu.h>
#include <linux/spinlock.h>
diff --git a/arch/powerpc/include/asm/rheap.h b/include/linux/fsl/rheap.h
similarity index 100%
rename from arch/powerpc/include/asm/rheap.h
rename to include/linux/fsl/rheap.h
diff --git a/lib/Kconfig b/lib/Kconfig
index 334f772..f5d5e99 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -393,6 +393,9 @@ config CPU_RMAP
bool
depends on SMP
+config LIB_RHEAP
+ bool
+
config DQL
bool
diff --git a/lib/Makefile b/lib/Makefile
index ba967a1..dccdef1 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -193,3 +193,5 @@ quiet_cmd_build_OID_registry = GEN $@
clean-files += oid_registry_data.c
obj-$(CONFIG_UCS2_STRING) += ucs2_string.o
+
+obj-$(CONFIG_LIB_RHEAP) += rheap.o
diff --git a/arch/powerpc/lib/rheap.c b/lib/rheap.c
similarity index 99%
rename from arch/powerpc/lib/rheap.c
rename to lib/rheap.c
index a1060a8..af180fd 100644
--- a/arch/powerpc/lib/rheap.c
+++ b/lib/rheap.c
@@ -20,7 +20,7 @@
#include <linux/err.h>
#include <linux/slab.h>
-#include <asm/rheap.h>
+#include <linux/fsl/rheap.h>
/*
* Fixup a list_head, needed when copying lists. If the pointers fall
--
2.1.0.27.g96db324
^ permalink raw reply related
* Re: [PATCH 1/2] ipr: Convert to generic DMA API
From: Christoph Hellwig @ 2014-10-30 9:11 UTC (permalink / raw)
To: Brian King
Cc: wenxiong, linux-scsi, paulus, Anton Blanchard, scottwood,
linuxppc-dev
In-Reply-To: <54512539.5040501@linux.vnet.ibm.com>
On Wed, Oct 29, 2014 at 12:34:49PM -0500, Brian King wrote:
> Acked-by: Brian King <brking@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)?
^ permalink raw reply
* [PATCH] powerpc: Added rcw registers to global utility registers
From: Igal.Liberman @ 2014-10-30 9:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, Igal Liberman, Emilian.Medve
From: Igal Liberman <Igal.Liberman@freescale.com>
The RCW registers are required for the future clock binding implementation.
Signed-off-by: Igal Liberman <Igal.Liberman@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
^ permalink raw reply related
* Re: [PATCH v3 3/3] rheap: move rheap.c from arch/powerpc/lib/ to lib/
From: Kumar Gala @ 2014-10-30 13:25 UTC (permalink / raw)
To: Zhao Qiang; +Cc: B07421, R63061, linuxppc-dev, linux-kernel
In-Reply-To: <1414654264-2596-3-git-send-email-B45475@freescale.com>
On Oct 30, 2014, at 2:31 AM, Zhao Qiang <B45475@freescale.com> wrote:
> qe need to use the rheap, so move it to public directory.
>
> Signed-off-by: Zhao Qiang <B45475@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
^ permalink raw reply
* Re: [PATCH v3 1/3] QE: move qe code from arch/powerpc to drivers/soc
From: Kumar Gala @ 2014-10-30 13:36 UTC (permalink / raw)
To: Zhao Qiang; +Cc: B07421, R63061, linuxppc-dev, linux-kernel
In-Reply-To: <1414654264-2596-1-git-send-email-B45475@freescale.com>
On Oct 30, 2014, at 2:31 AM, Zhao Qiang <B45475@freescale.com> wrote:
> LS1 is arm cpu and it has qe ip block.
> move qe code from platform directory to public directory.
>=20
> 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.
>=20
> Signed-off-by: Zhao Qiang <B45475@freescale.com>
> ---
> Changes for v2:
> - move code to driver/soc
> Changes for v3:
> - change drivers/soc/qe to drivers/soc/fsl-qe
>=20
> 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 =3D> drivers/soc/fsl-qe}/Makefile | 0
> .../sysdev/qe_lib =3D> drivers/soc/fsl-qe}/gpio.c | 2 +-
> .../sysdev/qe_lib =3D> drivers/soc/fsl-qe}/qe.c | 4 +-
> .../sysdev/qe_lib =3D> drivers/soc/fsl-qe}/qe_ic.c | 2 +-
> .../sysdev/qe_lib =3D> drivers/soc/fsl-qe}/qe_ic.h | 2 +-
> .../sysdev/qe_lib =3D> drivers/soc/fsl-qe}/qe_io.c | 2 +-
> .../sysdev/qe_lib =3D> drivers/soc/fsl-qe}/ucc.c | 6 +--
> .../qe_lib =3D> drivers/soc/fsl-qe}/ucc_fast.c | 8 ++--
> .../qe_lib =3D> drivers/soc/fsl-qe}/ucc_slow.c | 8 ++--
> .../sysdev/qe_lib =3D> 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 =3D> include/linux/fsl}/immap_qe.h | 0
> .../powerpc/include/asm =3D> include/linux/fsl}/qe.h | 2 +-
> .../include/asm =3D> include/linux/fsl}/qe_ic.h | 0
> .../include/asm =3D> include/linux/fsl}/ucc.h | 4 +-
> .../include/asm =3D> include/linux/fsl}/ucc_fast.h | 6 +--
> .../include/asm =3D> 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 =3D> drivers/soc/fsl-qe}/Makefile =
(100%)
> rename {arch/powerpc/sysdev/qe_lib =3D> drivers/soc/fsl-qe}/gpio.c =
(99%)
> rename {arch/powerpc/sysdev/qe_lib =3D> drivers/soc/fsl-qe}/qe.c (99%)
> rename {arch/powerpc/sysdev/qe_lib =3D> drivers/soc/fsl-qe}/qe_ic.c =
(99%)
> rename {arch/powerpc/sysdev/qe_lib =3D> drivers/soc/fsl-qe}/qe_ic.h =
(98%)
> rename {arch/powerpc/sysdev/qe_lib =3D> drivers/soc/fsl-qe}/qe_io.c =
(99%)
> rename {arch/powerpc/sysdev/qe_lib =3D> drivers/soc/fsl-qe}/ucc.c =
(98%)
> rename {arch/powerpc/sysdev/qe_lib =3D> drivers/soc/fsl-qe}/ucc_fast.c =
(98%)
> rename {arch/powerpc/sysdev/qe_lib =3D> drivers/soc/fsl-qe}/ucc_slow.c =
(98%)
> rename {arch/powerpc/sysdev/qe_lib =3D> drivers/soc/fsl-qe}/usb.c =
(96%)
> rename {arch/powerpc/include/asm =3D> include/linux/fsl}/immap_qe.h =
(100%)
> rename {arch/powerpc/include/asm =3D> include/linux/fsl}/qe.h (99%)
> rename {arch/powerpc/include/asm =3D> include/linux/fsl}/qe_ic.h =
(100%)
> rename {arch/powerpc/include/asm =3D> include/linux/fsl}/ucc.h (96%)
> rename {arch/powerpc/include/asm =3D> include/linux/fsl}/ucc_fast.h =
(98%)
> rename {arch/powerpc/include/asm =3D> 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 be looked to be converted to use the =
clk framework
These changes need to be addressed before any of the qe_lib code can get =
moved into drivers/soc
- k
^ permalink raw reply
* Re: [PATCH 1/2] ipr: Convert to generic DMA API
From: Brian King @ 2014-10-30 13:40 UTC (permalink / raw)
To: Christoph Hellwig
Cc: wenxiong, linux-scsi, paulus, Anton Blanchard, scottwood,
linuxppc-dev
In-Reply-To: <20141030091153.GA18224@infradead.org>
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 <brking@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
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/dts: Factorize the clock control node
From: Emil Medve @ 2014-10-30 13:58 UTC (permalink / raw)
To: Scott Wood; +Cc: yuantian.tang, linuxppc-dev, devicetree
In-Reply-To: <1414538500.23458.125.camel@snotra.buserror.net>
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.Medve@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 0000000..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 = "pll3", "pll3-div2", "pll3-div4";
>> };
>> -
>> pll4: pll4@880 {
>> #clock-cells = <1>;
>> reg = <0x880 0x4>;
>
> Why?
Why what?
Cheers,
^ permalink raw reply
* Re: [PATCH] powerpc: Added rcw registers to global utility registers
From: Emil Medve @ 2014-10-30 13:59 UTC (permalink / raw)
To: Igal.Liberman, linuxppc-dev; +Cc: scottwood
In-Reply-To: <1414660547-1488-1-git-send-email-igal.liberman@freescale.com>
On 10/30/2014 04:15 AM, Igal.Liberman wrote:
> From: Igal Liberman <Igal.Liberman@freescale.com>
>
> The RCW registers are required for the future clock binding implementation.
>
> Signed-off-by: Igal Liberman <Igal.Liberman@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.Medve@Freescale.com>
Cheers,
^ permalink raw reply
* Re: [PATCH] powerpc: Added rcw registers to global utility registers
From: Scott Wood @ 2014-10-30 14:47 UTC (permalink / raw)
To: Emil Medve; +Cc: Igal.Liberman, linuxppc-dev
In-Reply-To: <5452445F.7090803@Freescale.com>
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.Liberman@freescale.com>
> >
> > The RCW registers are required for the future clock binding implementation.
> >
> > Signed-off-by: Igal Liberman <Igal.Liberman@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.Medve@Freescale.com>
How were you involved in the patch or its submission? Did you mean
Reviewed-by or similar?
-Scott
^ permalink raw reply
* Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
From: Scott Wood @ 2014-10-30 14:51 UTC (permalink / raw)
To: Emil Medve
Cc: mark.rutland, devicetree, pawel.moll, corbet, Geoff.Thorpe,
ijc+devicetree, linux-doc, linuxppc-dev, robh+dt, Kumar Gala
In-Reply-To: <5451BF49.6050106@Freescale.com>
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.Medve@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.Medve@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
^ permalink raw reply
* Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
From: Emil Medve @ 2014-10-30 16:19 UTC (permalink / raw)
To: Scott Wood
Cc: mark.rutland, devicetree, pawel.moll, ijc+devicetree,
Geoff.Thorpe, corbet, linux-doc, linuxppc-dev, robh+dt,
Kumar Gala
In-Reply-To: <1414680683.23458.148.camel__4514.07629666409$1414680744$gmane$org@snotra.buserror.net>
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.Medve@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.Medve@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,
^ permalink raw reply
* Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
From: Scott Wood @ 2014-10-30 16:29 UTC (permalink / raw)
To: Emil Medve
Cc: mark.rutland, devicetree, pawel.moll, ijc+devicetree,
Geoff.Thorpe, corbet, linux-doc, linuxppc-dev, robh+dt,
Kumar Gala
In-Reply-To: <54526521.1090601@Freescale.com>
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.Medve@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.Medve@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
^ permalink raw reply
* RE: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
From: Varun Sethi @ 2014-10-30 15:10 UTC (permalink / raw)
To: Emilian Medve, Scott Wood, Kumar Gala
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
pawel.moll@arm.com, ijc+devicetree@hellion.org.uk, Geoff Thorpe,
corbet@lwn.net, linux-doc@vger.kernel.org,
linuxppc-dev@ozlabs.org, robh+dt@kernel.org, Rajan Srivastava
In-Reply-To: <54515ECB.70404@Freescale.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTGludXhwcGMtZGV2IFtt
YWlsdG86bGludXhwcGMtZGV2LQ0KPiBib3VuY2VzK3ZhcnVuLnNldGhpPWZyZWVzY2FsZS5jb21A
bGlzdHMub3psYWJzLm9yZ10gT24gQmVoYWxmIE9mIEVtaWwNCj4gTWVkdmUNCj4gU2VudDogVGh1
cnNkYXksIE9jdG9iZXIgMzAsIDIwMTQgMzoxMCBBTQ0KPiBUbzogV29vZCBTY290dC1CMDc0MjE7
IEt1bWFyIEdhbGENCj4gQ2M6IG1hcmsucnV0bGFuZEBhcm0uY29tOyBkZXZpY2V0cmVlQHZnZXIu
a2VybmVsLm9yZzsNCj4gcGF3ZWwubW9sbEBhcm0uY29tOyBjb3JiZXRAbHduLm5ldDsgVGhvcnBl
IEdlb2ZmLVIwMTM2MTsNCj4gaWpjK2RldmljZXRyZWVAaGVsbGlvbi5vcmcudWs7IGxpbnV4LWRv
Y0B2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLQ0KPiBkZXZAb3psYWJzLm9yZzsgcm9iaCtkdEBr
ZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMS80XSBkdC9iaW5kaW5nczogSW50cm9k
dWNlIHRoZSBGU0wgUW9ySVEgRFBBQSBCTWFuDQo+IA0KPiBIZWxsbyBTY290dCwNCj4gDQo+IA0K
PiBPbiAxMC8yOC8yMDE0IDAxOjA4IFBNLCBTY290dCBXb29kIHdyb3RlOg0KPiA+IE9uIFR1ZSwg
MjAxNC0xMC0yOCBhdCAwOTozNiAtMDUwMCwgS3VtYXIgR2FsYSB3cm90ZToNCj4gPj4gT24gT2N0
IDIyLCAyMDE0LCBhdCA5OjA5IEFNLCBFbWlsIE1lZHZlIDxFbWlsaWFuLk1lZHZlQGZyZWVzY2Fs
ZS5jb20+DQo+IHdyb3RlOg0KPiA+Pg0KPiA+Pj4gVGhlIEJ1ZmZlciBNYW5hZ2VyIGlzIHBhcnQg
b2YgdGhlIERhdGEtUGF0aCBBY2NlbGVyYXRpb24gQXJjaGl0ZWN0dXJlDQo+IChEUEFBKS4NCj4g
Pj4+IEJNYW4gc3VwcG9ydHMgaGFyZHdhcmUgYWxsb2NhdGlvbiBhbmQgZGVhbGxvY2F0aW9uIG9m
IGJ1ZmZlcnMNCj4gPj4+IGJlbG9uZ2luZyB0byBwb29scyBvcmlnaW5hbGx5IGNyZWF0ZWQgYnkg
c29mdHdhcmUgd2l0aCBjb25maWd1cmFibGUNCj4gZGVwbGV0aW9uIHRocmVzaG9sZHMuDQo+ID4+
PiBUaGlzIGJpbmRpbmcgY292ZXJzIHRoZSBDQ1NSIHNwYWNlIHByb2dyYW1taW5nIG1vZGVsDQo+
ID4+Pg0KPiA+Pj4gU2lnbmVkLW9mZi1ieTogRW1pbCBNZWR2ZSA8RW1pbGlhbi5NZWR2ZUBGcmVl
c2NhbGUuY29tPg0KPiA+Pj4gQ2hhbmdlLUlkOiBJM2VjNDc5YmZiM2M5MTk1MWU5NjkwMmYwOTFm
NWQ3ZDJhZGJlZjNiMg0KPiA+Pj4gLS0tDQo+ID4+PiAuLi4vZGV2aWNldHJlZS9iaW5kaW5ncy9w
b3dlcnBjL2ZzbC9ibWFuLnR4dCAgICAgICB8IDk4DQo+ICsrKysrKysrKysrKysrKysrKysrKysN
Cj4gPj4+IDEgZmlsZSBjaGFuZ2VkLCA5OCBpbnNlcnRpb25zKCspDQo+ID4+PiBjcmVhdGUgbW9k
ZSAxMDA2NDQNCj4gPj4+IERvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9wb3dlcnBj
L2ZzbC9ibWFuLnR4dA0KPiA+Pg0KPiA+PiBTaG91bGQgdGhlc2UgcmVhbGx5IGJlIGluIGJpbmRp
bmdzL3Bvd2VycGMvZnNsLCBhcmVu4oCZdCB5b3UgZ3V5cyB1c2luZyB0aGlzIG9uDQo+IEFSTSBT
b0NzIGFzIHdlbGw/DQo+ID4NCj4gPiBUaGUgaGFyZHdhcmUgb24gdGhlIEFSTSBTb0NzIGlzIGRp
ZmZlcmVudCBlbm91Z2ggdGhhdCBJJ20gbm90IHN1cmUgdGhlDQo+ID4gc2FtZSBiaW5kaW5nIHdp
bGwgY292ZXIgaXQuICBUaGF0IHNhaWQsIHB1dHRpbmcgdGhpbmdzIHVuZGVyIDxhcmNoPg0KPiA+
IHNob3VsZCBiZSBhIGxhc3QgcmVzb3J0IGlmIG5vd2hlcmUgZWxzZSBmaXRzLg0KPiANCj4gT1RD
IHN0YXJ0ZWQgcG9ydGVkIHRoZSBkcml2ZXIgdG8gdGhlIHRoZSBBUk0gU29DIGFuZCB0aGUgZmVl
ZGJhY2sgaGFzIGJlZW4NCj4gdGhhdCB0aGUgZHJpdmVyIG5lZWRlZCBtaW5pbWFsIGNoYW5nZXMu
IFRoZSBJT01NVSBoYXMgYmVlbiB0aGUgb25seSBhcmVhDQo+IG9mIGNvbmNlcm4sIGFuZCBhIHNt
YWxsIGNoYW5nZSB0byB0aGUgYmluZGluZyBoYXMgYmVlbiBzdWdnZXN0ZWQNCklPTU1VIHNwZWNp
ZmljIGJpbmRpbmcgd291bGQgYmUgZGlmZmVyZW50LiBUaGUgYmluZGluZyB3b3VsZCBoYXZlIHRv
IGNvbXBseSB0byB0aGUgYXJtLXNtbXUgYmluZGluZyAod2hpY2ggbmVlZHMgdG8gYmUgdXBkYXRl
ZCkuDQoNCi1WYXJ1bg0K
^ permalink raw reply
* Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
From: Emil Medve @ 2014-10-30 16:45 UTC (permalink / raw)
To: Scott Wood
Cc: mark.rutland, devicetree, pawel.moll, corbet, Geoff.Thorpe,
ijc+devicetree, linux-doc, linuxppc-dev, robh+dt, Kumar Gala
In-Reply-To: <1414686590.23458.151.camel__44619.4786033176$1414686664$gmane$org@snotra.buserror.net>
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.Medve@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.Medve@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,
^ permalink raw reply
* Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
From: Alexei Starovoitov @ 2014-10-30 20:32 UTC (permalink / raw)
To: Denis Kirjanov; +Cc: netdev@vger.kernel.org, Matt Evans, linuxppc-dev
In-Reply-To: <1414649535-3956-1-git-send-email-kda@linux-powerpc.org>
On Wed, Oct 29, 2014 at 11:12 PM, Denis Kirjanov <kda@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?
^ permalink raw reply
* Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
From: Scott Wood @ 2014-10-30 21:26 UTC (permalink / raw)
To: Emil Medve
Cc: mark.rutland, devicetree, pawel.moll, corbet, Geoff.Thorpe,
ijc+devicetree, linux-doc, linuxppc-dev, robh+dt, Kumar Gala
In-Reply-To: <54526B13.3010704@Freescale.com>
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.Medve@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.Medve@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
^ permalink raw reply
* Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
From: Emil Medve @ 2014-10-30 21:30 UTC (permalink / raw)
To: Scott Wood
Cc: mark.rutland, devicetree, pawel.moll, corbet, Geoff.Thorpe,
ijc+devicetree, linux-doc, linuxppc-dev, robh+dt, Kumar Gala
In-Reply-To: <1414704371.23458.157.camel@snotra.buserror.net>
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.Medve@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.Medve@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,
^ permalink raw reply
* [PATCH 1/3] ipr: Convert to generic DMA API
From: Brian King @ 2014-10-30 22:27 UTC (permalink / raw)
To: James.Bottomley; +Cc: hch, brking, linuxppc-dev, anton, linux-scsi
From: Anton Blanchard <anton@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 <anton@samba.org>
Signed-off-by: Brian King <brking@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 = pci_pool_create(IPR_NAME, ioa_cfg->pdev,
+ ioa_cfg->ipr_cmd_pool = dma_pool_create(IPR_NAME, &ioa_cfg->pdev->dev,
sizeof(struct ipr_cmnd), 512, 0);
if (!ioa_cfg->ipr_cmd_pool)
@@ -9029,7 +9029,7 @@ static int ipr_alloc_cmd_blks(struct ipr
}
for (i = 0; i < IPR_NUM_CMD_BLKS; i++) {
- ipr_cmd = pci_pool_alloc(ioa_cfg->ipr_cmd_pool, GFP_KERNEL, &dma_addr);
+ ipr_cmd = dma_pool_alloc(ioa_cfg->ipr_cmd_pool, GFP_KERNEL, &dma_addr);
if (!ipr_cmd) {
ipr_free_cmd_blks(ioa_cfg);
@@ -9100,9 +9100,10 @@ static int ipr_alloc_mem(struct ipr_ioa_
ioa_cfg->res_entries[i].ioa_cfg = ioa_cfg;
}
- ioa_cfg->vpd_cbs = pci_alloc_consistent(ioa_cfg->pdev,
- sizeof(struct ipr_misc_cbs),
- &ioa_cfg->vpd_cbs_dma);
+ ioa_cfg->vpd_cbs = dma_alloc_coherent(&pdev->dev,
+ sizeof(struct ipr_misc_cbs),
+ &ioa_cfg->vpd_cbs_dma,
+ GFP_KERNEL);
if (!ioa_cfg->vpd_cbs)
goto out_free_res_entries;
@@ -9111,13 +9112,14 @@ static int ipr_alloc_mem(struct ipr_ioa_
goto out_free_vpd_cbs;
for (i = 0; i < ioa_cfg->hrrq_num; i++) {
- ioa_cfg->hrrq[i].host_rrq = pci_alloc_consistent(ioa_cfg->pdev,
+ ioa_cfg->hrrq[i].host_rrq = dma_alloc_coherent(&pdev->dev,
sizeof(u32) * ioa_cfg->hrrq[i].size,
- &ioa_cfg->hrrq[i].host_rrq_dma);
+ &ioa_cfg->hrrq[i].host_rrq_dma,
+ GFP_KERNEL);
if (!ioa_cfg->hrrq[i].host_rrq) {
while (--i > 0)
- pci_free_consistent(pdev,
+ dma_free_coherent(&pdev->dev,
sizeof(u32) * ioa_cfg->hrrq[i].size,
ioa_cfg->hrrq[i].host_rrq,
ioa_cfg->hrrq[i].host_rrq_dma);
@@ -9126,17 +9128,19 @@ static int ipr_alloc_mem(struct ipr_ioa_
ioa_cfg->hrrq[i].ioa_cfg = ioa_cfg;
}
- ioa_cfg->u.cfg_table = pci_alloc_consistent(ioa_cfg->pdev,
- ioa_cfg->cfg_table_size,
- &ioa_cfg->cfg_table_dma);
+ ioa_cfg->u.cfg_table = dma_alloc_coherent(&pdev->dev,
+ ioa_cfg->cfg_table_size,
+ &ioa_cfg->cfg_table_dma,
+ GFP_KERNEL);
if (!ioa_cfg->u.cfg_table)
goto out_free_host_rrq;
for (i = 0; i < IPR_NUM_HCAMS; i++) {
- ioa_cfg->hostrcb[i] = pci_alloc_consistent(ioa_cfg->pdev,
- sizeof(struct ipr_hostrcb),
- &ioa_cfg->hostrcb_dma[i]);
+ ioa_cfg->hostrcb[i] = dma_alloc_coherent(&pdev->dev,
+ sizeof(struct ipr_hostrcb),
+ &ioa_cfg->hostrcb_dma[i],
+ GFP_KERNEL);
if (!ioa_cfg->hostrcb[i])
goto out_free_hostrcb_dma;
@@ -9160,25 +9164,24 @@ out:
out_free_hostrcb_dma:
while (i-- > 0) {
- pci_free_consistent(pdev, sizeof(struct ipr_hostrcb),
- ioa_cfg->hostrcb[i],
- ioa_cfg->hostrcb_dma[i]);
- }
- pci_free_consistent(pdev, ioa_cfg->cfg_table_size,
- ioa_cfg->u.cfg_table,
- ioa_cfg->cfg_table_dma);
+ dma_free_coherent(&pdev->dev, sizeof(struct ipr_hostrcb),
+ ioa_cfg->hostrcb[i],
+ ioa_cfg->hostrcb_dma[i]);
+ }
+ dma_free_coherent(&pdev->dev, ioa_cfg->cfg_table_size,
+ ioa_cfg->u.cfg_table, ioa_cfg->cfg_table_dma);
out_free_host_rrq:
for (i = 0; i < ioa_cfg->hrrq_num; i++) {
- pci_free_consistent(pdev,
- sizeof(u32) * ioa_cfg->hrrq[i].size,
- ioa_cfg->hrrq[i].host_rrq,
- ioa_cfg->hrrq[i].host_rrq_dma);
+ dma_free_coherent(&pdev->dev,
+ sizeof(u32) * ioa_cfg->hrrq[i].size,
+ ioa_cfg->hrrq[i].host_rrq,
+ ioa_cfg->hrrq[i].host_rrq_dma);
}
out_ipr_free_cmd_blocks:
ipr_free_cmd_blks(ioa_cfg);
out_free_vpd_cbs:
- pci_free_consistent(pdev, sizeof(struct ipr_misc_cbs),
- ioa_cfg->vpd_cbs, ioa_cfg->vpd_cbs_dma);
+ dma_free_coherent(&pdev->dev, sizeof(struct ipr_misc_cbs),
+ ioa_cfg->vpd_cbs, ioa_cfg->vpd_cbs_dma);
out_free_res_entries:
kfree(ioa_cfg->res_entries);
goto out;
@@ -9618,13 +9621,13 @@ static int ipr_probe_ioa(struct pci_dev
ipr_init_regs(ioa_cfg);
if (ioa_cfg->sis64) {
- rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
+ rc = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (rc < 0) {
dev_dbg(&pdev->dev, "Failed to set 64 bit PCI DMA mask\n");
- rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
+ rc = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
}
} else
- rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
+ rc = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (rc < 0) {
dev_err(&pdev->dev, "Failed to set PCI DMA mask\n");
diff -puN drivers/scsi/ipr.h~ipr_convert_to_generic_DMA_API drivers/scsi/ipr.h
--- scsi-queue/drivers/scsi/ipr.h~ipr_convert_to_generic_DMA_API 2014-10-30 17:15:26.138856575 -0500
+++ scsi-queue-bjking1/drivers/scsi/ipr.h 2014-10-30 17:15:26.148856485 -0500
@@ -1549,7 +1549,7 @@ struct ipr_ioa_cfg {
struct ipr_misc_cbs *vpd_cbs;
dma_addr_t vpd_cbs_dma;
- struct pci_pool *ipr_cmd_pool;
+ struct dma_pool *ipr_cmd_pool;
struct ipr_cmnd *reset_cmd;
int (*reset) (struct ipr_cmnd *);
_
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox