* [PATCH] powerpc: Fix 64 bit builds with binutils 2.24
From: Guenter Roeck @ 2014-05-15 16:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, linux-kernel, Guenter Roeck,
Alan Modra
With binutils 2.24, various 64 bit builds fail with relocation errors
such as
arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
(.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI
against symbol `interrupt_base_book3e' defined in .text section
in arch/powerpc/kernel/built-in.o
arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
(.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI
against symbol `interrupt_end_book3e' defined in .text section
in arch/powerpc/kernel/built-in.o
The assembler maintainer says:
I changed the ABI, something that had to be done but unfortunately
happens to break the booke kernel code. When building up a 64-bit
value with lis, ori, shl, oris, ori or similar sequences, you now
should use @high and @higha in place of @h and @ha. @h and @ha
(and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA)
now report overflow if the value is out of 32-bit signed range.
ie. @h and @ha assume you're building a 32-bit value. This is needed
to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h
and @toc@ha expressions, and for consistency I did the same for all
other @h and @ha relocs.
Replacing @h with @high in one strategic location fixes the relocation
errors. This has to be done conditionally since the assembler either
supports @h or @high but not both.
Cc: Alan Modra <amodra@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
All my test targets build with both binutils 2.23 and 2.24
with this patch applied.
The patch generates two checkpatch errors, but I consider those to be
false positives. checkpatch requests spaces after , in the assembler
instructions.
Please consider adding Cc: stable.
arch/powerpc/Makefile | 4 +++-
arch/powerpc/include/asm/ppc_asm.h | 7 ++++++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 4c0cedf..ce4c68a 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -150,7 +150,9 @@ endif
CFLAGS-$(CONFIG_TUNE_CELL) += $(call cc-option,-mtune=cell)
-KBUILD_CPPFLAGS += -Iarch/$(ARCH)
+asinstr := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
+
+KBUILD_CPPFLAGS += -Iarch/$(ARCH) $(asinstr)
KBUILD_AFLAGS += -Iarch/$(ARCH)
KBUILD_CFLAGS += -msoft-float -pipe -Iarch/$(ARCH) $(CFLAGS-y)
CPP = $(CC) -E $(KBUILD_CFLAGS)
diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h
index 6586a40..cded7c1 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -318,11 +318,16 @@ n:
addi reg,reg,(name - 0b)@l;
#ifdef __powerpc64__
+#ifdef HAVE_AS_ATHIGH
+#define __AS_ATHIGH high
+#else
+#define __AS_ATHIGH h
+#endif
#define LOAD_REG_IMMEDIATE(reg,expr) \
lis reg,(expr)@highest; \
ori reg,reg,(expr)@higher; \
rldicr reg,reg,32,31; \
- oris reg,reg,(expr)@h; \
+ oris reg,reg,(expr)@__AS_ATHIGH; \
ori reg,reg,(expr)@l;
#define LOAD_REG_ADDR(reg,name) \
--
1.9.1
^ permalink raw reply related
* [PATCH] selftests: PAGE_SIZE may not be defined
From: Thierry Fauck ( thierry @ linux.vnet.ibm.com ) @ 2014-05-15 16:02 UTC (permalink / raw)
To: benh, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]
Hi Ben,
The following patch seems relevant for Ubuntu and Debian distro testing.
I know it's minor but I need to know if you do you care about it or sif
I should remove it from the bugs info.
Thanks
Best regards
Thierry
#---------------------------------------------------------------------------------------------------
>From 48a9a9834377a74b603be12dcc76cda24105e33c Mon Sep 17 00:00:00 2001
From: Thierry Fauck <thierry@linux.vnet.ibm.com>
Date: Fri, 28 Feb 2014 16:17:50 +0100
Subject: [PATCH] selftests: PAGE_SIZE may not be defined
Some systems have a dynamic PAGE_SIZE value and do not add a definition
for PAGE_SIZE. This value will have to be retrieved using getpagesize()
or sysconf().
Signed-off-by: Thierry Fauck <thierry@linux.vnet.ibm.com>
---
tools/testing/selftests/ptrace/peeksiginfo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ptrace/peeksiginfo.c
b/tools/testing/selftests/ptrace/peeksiginfo.c
index d46558b..f2ccbbd 100644
--- a/tools/testing/selftests/ptrace/peeksiginfo.c
+++ b/tools/testing/selftests/ptrace/peeksiginfo.c
@@ -35,7 +35,9 @@ static int sys_ptrace(int request, pid_t pid, void
*addr, void *data)
fprintf(stderr, \
"Error (%s:%d): " fmt, \
__FILE__, __LINE__, ##__VA_ARGS__)
-
+#ifndef PAGE_SIZE
+#define PAGE_SIZE sysconf(_SC_PAGESIZE)
+#endif
static int check_error_paths(pid_t child)
{
struct ptrace_peeksiginfo_args arg;
--
1.9.0
--
Thierry Fauck (thierry@linux.vnet.ibm.com)
[-- Attachment #2: Type: text/html, Size: 2508 bytes --]
^ permalink raw reply related
* Re: [PATCH 3/3] of: Handle memory@0 node on PPC32 only
From: Grant Likely @ 2014-05-15 14:59 UTC (permalink / raw)
To: Leif Lindholm, Mark Rutland
Cc: devicetree@vger.kernel.org, patches@linaro.org, Lee Jones,
linux-kernel@vger.kernel.org, Rob Herring, Geert Uytterhoeven,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20140424092642.GQ5904@bivouac.eciton.net>
On Thu, 24 Apr 2014 10:26:42 +0100, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> On Wed, Apr 23, 2014 at 02:10:58PM +0100, Grant Likely wrote:
> > > Does anyone have a LongTrail DT to hand, and if so does the root have a
> > > compatible string? From grepping through the kernel I could only find a
> > > model string ("IBM,LongTrail").
> >
> > Actually, on LongTrail this can be removed from the common code
> > entirely. It has real open firmware and PowerPC already has the
> > infrastructure for fixing up the device tree.
> >
> > Here's a draft patch that I've compile tested, but nothing else.
>
> I would certainly be happy with that.
>
> Consider my 3/3 withdrawn.
>
> And if the kernel proper will stop honoring nodes with no type,
> there is no need for the stub to treat those specially either.
So, after thinking about it some more, I've changed my minde about the
whole thing again. The impact is quite contained because there weren't a
lot of systems that had ram based at 0. I'm going to commit this patch,
but I'll include a note in the commit text that if it causes trouble for
anyone that they should yell and I'll revert it. I don't think it will
though.
g.
^ permalink raw reply
* Re: roundup_pow_of_two() may not handle 64-bit integers
From: David Howells @ 2014-05-15 15:03 UTC (permalink / raw)
To: Brian Norris
Cc: Linux Kernel, dhowells, Paul Mackerras, Andrew Morton,
linuxppc-dev
In-Reply-To: <20140515022238.GL28907@ld-irv-0074>
Brian Norris <computersforpeace@gmail.com> wrote:
> I'm looking to use roundup_pow_of_two() (actually, order_base_2())
> from <linux/log2.h>, but it seems that it only supports 64-bit integers
> if your toolchain uses a 64-bit 'unsigned long' type. This is strange,
> considering that ilog2() is explicitly designed for 32-bit or 64-bit
> compatibility.
ilog2() was explicitly designed for use with 'unsigned long'. See the commit
description (f0d1b0b30d250a07627ad8b9fbbb5c7cc08422e8). It may work with
unsigned long long, however...
David
^ permalink raw reply
* [PATCH RFC v13 5/5] dma: mpc512x: register for device tree channel lookup
From: Alexander Popov @ 2014-05-15 14:15 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine
Cc: devicetree
In-Reply-To: <1400163335-29853-1-git-send-email-a13xp0p0v88@gmail.com>
Register the controller for device tree based lookup of DMA channels
(non-fatal for backwards compatibility with older device trees) and
provide the '#dma-cells' property in the shared mpc5121.dtsi file
Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
---
arch/powerpc/boot/dts/mpc5121.dtsi | 1 +
drivers/dma/mpc512x_dma.c | 13 ++++++++++++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi b/arch/powerpc/boot/dts/mpc5121.dtsi
index 2c0e155..7f9d14f 100644
--- a/arch/powerpc/boot/dts/mpc5121.dtsi
+++ b/arch/powerpc/boot/dts/mpc5121.dtsi
@@ -498,6 +498,7 @@
compatible = "fsl,mpc5121-dma";
reg = <0x14000 0x1800>;
interrupts = <65 0x8>;
+ #dma-cells = <1>;
};
};
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 2ad4373..881db2b 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -53,6 +53,7 @@
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/of_irq.h>
+#include <linux/of_dma.h>
#include <linux/of_platform.h>
#include <linux/random.h>
@@ -1036,7 +1037,15 @@ static int mpc_dma_probe(struct platform_device *op)
if (retval)
goto err_free2;
- return retval;
+ /* Register with OF helpers for DMA lookups (nonfatal) */
+ if (dev->of_node) {
+ retval = of_dma_controller_register(dev->of_node,
+ of_dma_xlate_by_chan_id, mdma);
+ if (retval)
+ dev_warn(dev, "Could not register for OF lookup\n");
+ }
+
+ return 0;
err_free2:
if (mdma->is_mpc8308)
@@ -1057,6 +1066,8 @@ static int mpc_dma_remove(struct platform_device *op)
struct device *dev = &op->dev;
struct mpc_dma *mdma = dev_get_drvdata(dev);
+ if (dev->of_node)
+ of_dma_controller_free(dev->of_node);
dma_async_device_unregister(&mdma->dma);
if (mdma->is_mpc8308) {
free_irq(mdma->irq2, mdma);
--
1.8.4.2
^ permalink raw reply related
* [PATCH RFC v13 4/5] dma: mpc512x: add device tree binding document
From: Alexander Popov @ 2014-05-15 14:15 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine
Cc: devicetree
In-Reply-To: <1400163335-29853-1-git-send-email-a13xp0p0v88@gmail.com>
Introduce a device tree binding document for the MPC512x DMA controller
Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
---
.../devicetree/bindings/dma/mpc512x-dma.txt | 40 ++++++++++++++++++++++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
diff --git a/Documentation/devicetree/bindings/dma/mpc512x-dma.txt b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
new file mode 100644
index 0000000..b1cbc3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
@@ -0,0 +1,40 @@
+* Freescale MPC512x and MPC8308 DMA Controller
+
+The DMA controller in Freescale MPC512x and MPC8308 SoCs can move
+blocks of memory contents between memory and peripherals or
+from memory to memory.
+
+Refer to "Generic DMA Controller and DMA request bindings" in
+the dma/dma.txt file for a more detailed description of binding.
+
+Required properties:
+- compatible: Should be "fsl,mpc5121-dma" or "fsl,mpc8308-dma"
+- reg: Address and size of the DMA controller's register set
+- Interrupt for the DMA controller. Syntax of interrupt client node
+ is described in interrupt-controller/interrupts.txt
+
+Optional properties:
+- #dma-cells: The length of the DMA specifier, must be <1>.
+ Each channel of this DMA controller has a peripheral request line,
+ this assignment is fixed in hardware. The cell in dmas property
+ of a client device represents the channel number
+
+Example:
+
+ dma0: dma@14000 {
+ compatible = "fsl,mpc5121-dma";
+ reg = <0x14000 0x1800>;
+ interrupts = <65 0x8>;
+ #dma-cells = <1>;
+ };
+
+DMA clients must use the format described in dma/dma.txt
+
+Example:
+
+ sdhc@1500 {
+ compatible = "fsl,mpc5121-sdhc";
+ /* ... */
+ dmas = <&dma0 30>;
+ dma-names = "rx-tx";
+ };
--
1.8.4.2
^ permalink raw reply related
* [PATCH RFC v13 3/5] dma: of: add common xlate function for matching by channel id
From: Alexander Popov @ 2014-05-15 14:15 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine
Cc: devicetree
In-Reply-To: <1400163335-29853-1-git-send-email-a13xp0p0v88@gmail.com>
This patch adds a new common OF dma xlate callback function which will match a
channel by it's id. The binding expects one integer argument which it will use to
lookup the channel by the id.
Unlike of_dma_simple_xlate this function is able to handle a system with
multiple DMA controllers. When registering the of dma provider with
of_dma_controller_register a pointer to the dma_device struct which is
associated with the dt node needs to passed as the data parameter.
New function will use this pointer to match only channels which belong to the
specified DMA controller.
Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
---
drivers/dma/of-dma.c | 35 +++++++++++++++++++++++++++++++++++
include/linux/of_dma.h | 4 ++++
2 files changed, 39 insertions(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index e8fe9dc..d5fbeaa 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -218,3 +218,38 @@ struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
&dma_spec->args[0]);
}
EXPORT_SYMBOL_GPL(of_dma_simple_xlate);
+
+/**
+ * of_dma_xlate_by_chan_id - Translate dt property to DMA channel by channel id
+ * @dma_spec: pointer to DMA specifier as found in the device tree
+ * @of_dma: pointer to DMA controller data
+ *
+ * This function can be used as the of xlate callback for DMA driver which wants
+ * to match the channel based on the channel id. When using this xlate function
+ * the #dma-cells propety of the DMA controller dt node needs to be set to 1.
+ * The data parameter of of_dma_controller_register must be a pointer to the
+ * dma_device struct the function should match upon.
+ *
+ * Returns pointer to appropriate dma channel on success or NULL on error.
+ */
+struct dma_chan *of_dma_xlate_by_chan_id(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct dma_device *dev = ofdma->of_dma_data;
+ struct dma_chan *chan, *candidate = NULL;
+
+ if (!dev || dma_spec->args_count != 1)
+ return NULL;
+
+ list_for_each_entry(chan, &dev->channels, device_node)
+ if (chan->chan_id == dma_spec->args[0]) {
+ candidate = chan;
+ break;
+ }
+
+ if (!candidate)
+ return NULL;
+
+ return dma_get_slave_channel(candidate);
+}
+EXPORT_SYMBOL_GPL(of_dma_xlate_by_chan_id);
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index ae36298..56bc026 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -41,6 +41,8 @@ extern struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
const char *name);
extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma);
+extern struct dma_chan *of_dma_xlate_by_chan_id(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma);
#else
static inline int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
@@ -66,6 +68,8 @@ static inline struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_s
return NULL;
}
+#define of_dma_xlate_by_chan_id NULL
+
#endif
#endif /* __LINUX_OF_DMA_H */
--
1.8.4.2
^ permalink raw reply related
* [PATCH RFC v13 2/5] dma: mpc512x: add support for peripheral transfers
From: Alexander Popov @ 2014-05-15 14:15 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine
In-Reply-To: <1400163335-29853-1-git-send-email-a13xp0p0v88@gmail.com>
Introduce support for slave s/g transfer preparation and the associated
device control callback in the MPC512x DMA controller driver, which adds
support for data transfers between memory and peripheral I/O to the
previously supported mem-to-mem transfers.
Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
---
drivers/dma/mpc512x_dma.c | 244 +++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 239 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 96104f4..2ad4373 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -2,6 +2,7 @@
* Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
* Copyright (C) Semihalf 2009
* Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2014
*
* Written by Piotr Ziecik <kosmo@semihalf.com>. Hardware description
* (defines, structures and comments) was taken from MPC5121 DMA driver
@@ -29,8 +30,18 @@
*/
/*
- * This is initial version of MPC5121 DMA driver. Only memory to memory
- * transfers are supported (tested using dmatest module).
+ * MPC512x and MPC8308 DMA driver. It supports
+ * memory to memory data transfers (tested using dmatest module) and
+ * data transfers between memory and peripheral I/O memory
+ * by means of slave scatter/gather with these limitations:
+ * - chunked transfers (described by s/g lists with more than one item)
+ * are refused as long as proper support for scatter/gather is missing;
+ * - transfers on MPC8308 always start from software as this SoC appears
+ * not to have external request lines for peripheral flow control;
+ * - only peripheral devices with 4-byte FIFO access register are supported;
+ * - minimal memory <-> I/O memory transfer chunk is 4 bytes and consequently
+ * source and destination addresses must be 4-byte aligned
+ * and transfer size must be aligned on (4 * maxburst) boundary;
*/
#include <linux/module.h>
@@ -189,6 +200,7 @@ struct mpc_dma_desc {
dma_addr_t tcd_paddr;
int error;
struct list_head node;
+ int will_access_peripheral;
};
struct mpc_dma_chan {
@@ -201,6 +213,12 @@ struct mpc_dma_chan {
struct mpc_dma_tcd *tcd;
dma_addr_t tcd_paddr;
+ /* Settings for access to peripheral FIFO */
+ dma_addr_t src_per_paddr;
+ u32 src_tcd_nunits;
+ dma_addr_t dst_per_paddr;
+ u32 dst_tcd_nunits;
+
/* Lock for this structure */
spinlock_t lock;
};
@@ -251,8 +269,23 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
struct mpc_dma_desc *mdesc;
int cid = mchan->chan.chan_id;
- /* Move all queued descriptors to active list */
- list_splice_tail_init(&mchan->queued, &mchan->active);
+ while (!list_empty(&mchan->queued)) {
+ mdesc = list_first_entry(&mchan->queued,
+ struct mpc_dma_desc, node);
+ /*
+ * Grab either several mem-to-mem transfer descriptors
+ * or one peripheral transfer descriptor,
+ * don't mix mem-to-mem and peripheral transfer descriptors
+ * within the same 'active' list.
+ */
+ if (mdesc->will_access_peripheral) {
+ if (list_empty(&mchan->active))
+ list_move_tail(&mdesc->node, &mchan->active);
+ break;
+ } else {
+ list_move_tail(&mdesc->node, &mchan->active);
+ }
+ }
/* Chain descriptors into one transaction */
list_for_each_entry(mdesc, &mchan->active, node) {
@@ -278,7 +311,17 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
if (first != prev)
mdma->tcd[cid].e_sg = 1;
- out_8(&mdma->regs->dmassrt, cid);
+
+ if (mdma->is_mpc8308) {
+ /* MPC8308, no request lines, software initiated start */
+ out_8(&mdma->regs->dmassrt, cid);
+ } else if (first->will_access_peripheral) {
+ /* Peripherals involved, start by external request signal */
+ out_8(&mdma->regs->dmaserq, cid);
+ } else {
+ /* Memory to memory transfer, software initiated start */
+ out_8(&mdma->regs->dmassrt, cid);
+ }
}
/* Handle interrupt on one half of DMA controller (32 channels) */
@@ -596,6 +639,7 @@ mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t dst, dma_addr_t src,
}
mdesc->error = 0;
+ mdesc->will_access_peripheral = 0;
tcd = mdesc->tcd;
/* Prepare Transfer Control Descriptor for this transaction */
@@ -643,6 +687,193 @@ mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t dst, dma_addr_t src,
return &mdesc->desc;
}
+static struct dma_async_tx_descriptor *
+mpc_dma_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
+ unsigned int sg_len, enum dma_transfer_direction direction,
+ unsigned long flags, void *context)
+{
+ struct mpc_dma *mdma = dma_chan_to_mpc_dma(chan);
+ struct mpc_dma_chan *mchan = dma_chan_to_mpc_dma_chan(chan);
+ struct mpc_dma_desc *mdesc = NULL;
+ dma_addr_t per_paddr;
+ u32 tcd_nunits;
+ struct mpc_dma_tcd *tcd;
+ unsigned long iflags;
+ struct scatterlist *sg;
+ size_t len;
+ int iter, i;
+
+ /* Currently there is no proper support for scatter/gather */
+ if (sg_len != 1)
+ return NULL;
+
+ if (!is_slave_direction(direction))
+ return NULL;
+
+ for_each_sg(sgl, sg, sg_len, i) {
+ spin_lock_irqsave(&mchan->lock, iflags);
+
+ mdesc = list_first_entry(&mchan->free,
+ struct mpc_dma_desc, node);
+ if (!mdesc) {
+ spin_unlock_irqrestore(&mchan->lock, iflags);
+ /* Try to free completed descriptors */
+ mpc_dma_process_completed(mdma);
+ return NULL;
+ }
+
+ list_del(&mdesc->node);
+
+ if (direction == DMA_DEV_TO_MEM) {
+ per_paddr = mchan->src_per_paddr;
+ tcd_nunits = mchan->src_tcd_nunits;
+ } else {
+ per_paddr = mchan->dst_per_paddr;
+ tcd_nunits = mchan->dst_tcd_nunits;
+ }
+
+ spin_unlock_irqrestore(&mchan->lock, iflags);
+
+ if (per_paddr == 0 || tcd_nunits == 0)
+ goto err_prep;
+
+ mdesc->error = 0;
+ mdesc->will_access_peripheral = 1;
+
+ /* Prepare Transfer Control Descriptor for this transaction */
+ tcd = mdesc->tcd;
+
+ memset(tcd, 0, sizeof(struct mpc_dma_tcd));
+
+ if (!IS_ALIGNED(sg_dma_address(sg), 4))
+ goto err_prep;
+
+ if (direction == DMA_DEV_TO_MEM) {
+ tcd->saddr = per_paddr;
+ tcd->daddr = sg_dma_address(sg);
+ tcd->soff = 0;
+ tcd->doff = 4;
+ } else {
+ tcd->saddr = sg_dma_address(sg);
+ tcd->daddr = per_paddr;
+ tcd->soff = 4;
+ tcd->doff = 0;
+ }
+
+ tcd->ssize = MPC_DMA_TSIZE_4;
+ tcd->dsize = MPC_DMA_TSIZE_4;
+
+ len = sg_dma_len(sg);
+ tcd->nbytes = tcd_nunits * 4;
+ if (!IS_ALIGNED(len, tcd->nbytes))
+ goto err_prep;
+
+ iter = len / tcd->nbytes;
+ if (iter >= 1 << 15) {
+ /* len is too big */
+ goto err_prep;
+ }
+ /* citer_linkch contains the high bits of iter */
+ tcd->biter = iter & 0x1ff;
+ tcd->biter_linkch = iter >> 9;
+ tcd->citer = tcd->biter;
+ tcd->citer_linkch = tcd->biter_linkch;
+
+ tcd->e_sg = 0;
+ tcd->d_req = 1;
+
+ /* Place descriptor in prepared list */
+ spin_lock_irqsave(&mchan->lock, iflags);
+ list_add_tail(&mdesc->node, &mchan->prepared);
+ spin_unlock_irqrestore(&mchan->lock, iflags);
+ }
+
+ return &mdesc->desc;
+
+err_prep:
+ /* Put the descriptor back */
+ spin_lock_irqsave(&mchan->lock, iflags);
+ list_add_tail(&mdesc->node, &mchan->free);
+ spin_unlock_irqrestore(&mchan->lock, iflags);
+
+ return NULL;
+}
+
+static int mpc_dma_device_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
+ unsigned long arg)
+{
+ struct mpc_dma_chan *mchan;
+ struct mpc_dma *mdma;
+ struct dma_slave_config *cfg;
+ unsigned long flags;
+
+ mchan = dma_chan_to_mpc_dma_chan(chan);
+ switch (cmd) {
+ case DMA_TERMINATE_ALL:
+ /* Disable channel requests */
+ mdma = dma_chan_to_mpc_dma(chan);
+
+ spin_lock_irqsave(&mchan->lock, flags);
+
+ out_8(&mdma->regs->dmacerq, chan->chan_id);
+ list_splice_tail_init(&mchan->prepared, &mchan->free);
+ list_splice_tail_init(&mchan->queued, &mchan->free);
+ list_splice_tail_init(&mchan->active, &mchan->free);
+
+ spin_unlock_irqrestore(&mchan->lock, flags);
+
+ return 0;
+
+ case DMA_SLAVE_CONFIG:
+ /*
+ * Software constraints:
+ * - only transfers between a peripheral device and
+ * memory are supported;
+ * - only peripheral devices with 4-byte FIFO access register
+ * are supported;
+ * - minimal transfer chunk is 4 bytes and consequently
+ * source and destination addresses must be 4-byte aligned
+ * and transfer size must be aligned on (4 * maxburst)
+ * boundary;
+ * - during the transfer RAM address is being incremented by
+ * the size of minimal transfer chunk;
+ * - peripheral port's address is constant during the transfer.
+ */
+
+ cfg = (void *)arg;
+
+ if (cfg->src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES ||
+ cfg->dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES ||
+ !IS_ALIGNED(cfg->src_addr, 4) ||
+ !IS_ALIGNED(cfg->dst_addr, 4)) {
+ return -EINVAL;
+ }
+
+ spin_lock_irqsave(&mchan->lock, flags);
+
+ mchan->src_per_paddr = cfg->src_addr;
+ mchan->src_tcd_nunits = cfg->src_maxburst;
+ mchan->dst_per_paddr = cfg->dst_addr;
+ mchan->dst_tcd_nunits = cfg->dst_maxburst;
+
+ /* Apply defaults */
+ if (mchan->src_tcd_nunits == 0)
+ mchan->src_tcd_nunits = 1;
+ if (mchan->dst_tcd_nunits == 0)
+ mchan->dst_tcd_nunits = 1;
+
+ spin_unlock_irqrestore(&mchan->lock, flags);
+
+ return 0;
+
+ default:
+ /* Unknown command */
+ break;
+ }
+
+ return -ENXIO;
+}
+
static int mpc_dma_probe(struct platform_device *op)
{
struct device_node *dn = op->dev.of_node;
@@ -733,9 +964,12 @@ static int mpc_dma_probe(struct platform_device *op)
dma->device_issue_pending = mpc_dma_issue_pending;
dma->device_tx_status = mpc_dma_tx_status;
dma->device_prep_dma_memcpy = mpc_dma_prep_memcpy;
+ dma->device_prep_slave_sg = mpc_dma_prep_slave_sg;
+ dma->device_control = mpc_dma_device_control;
INIT_LIST_HEAD(&dma->channels);
dma_cap_set(DMA_MEMCPY, dma->cap_mask);
+ dma_cap_set(DMA_SLAVE, dma->cap_mask);
for (i = 0; i < dma->chancnt; i++) {
mchan = &mdma->channels[i];
--
1.8.4.2
^ permalink raw reply related
* [PATCH RFC v13 1/5] dmaengine: fix comment typo
From: Alexander Popov @ 2014-05-15 14:15 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine
In-Reply-To: <1400163335-29853-1-git-send-email-a13xp0p0v88@gmail.com>
Fix comment typo.
Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
---
include/linux/dmaengine.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 8300fb8..cbb168e 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -292,7 +292,7 @@ struct dma_chan_dev {
};
/**
- * enum dma_slave_buswidth - defines bus with of the DMA slave
+ * enum dma_slave_buswidth - defines bus width of the DMA slave
* device, source or target buses
*/
enum dma_slave_buswidth {
--
1.8.4.2
^ permalink raw reply related
* [PATCH RFC v13 0/5] MPC512x DMA slave s/g support, OF DMA lookup
From: Alexander Popov @ 2014-05-15 14:15 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine
Cc: devicetree
2013/7/14 Gerhard Sittig <gsi@denx.de>:
> this series
> - introduces slave s/g support (that's support for DMA transfers which
> involve peripherals in contrast to mem-to-mem transfers)
> - adds device tree based lookup support for DMA channels
> - combines floating patches and related feedback which already covered
> several aspects of what the suggested LPB driver needs, to demonstrate
> how integration might be done
...
Changes in v12:
A new patch (part 2/7) is added to this series.
Part 6/7:
- change the description of 'compatible' property according part 2/7;
- improve the document according Gerhard's feedback;
Parts 1/7, 2/7 and 4/7 have been applied by Vinod Koul and
are excluded from v13.
Changes in v13:
A new patch (part 1/5) is added to this series.
Part 2/5:
- fix style issue;
- improve comments;
> known issues:
> - it's yet to get confirmed whether MPC8308 can use slave support or
> whether the DMA controller's driver shall actively reject it, the
> information that's available so far suggests that peripheral transfers
> to IP bus attached I/O is useful and shall not get blocked right away
Alexander Popov (5):
dmaengine: fix comment typo
dma: mpc512x: add support for peripheral transfers
dma: of: add common xlate function for matching by channel id
dma: mpc512x: add device tree binding document
dma: mpc512x: register for device tree channel lookup
.../devicetree/bindings/dma/mpc512x-dma.txt | 40 ++++
arch/powerpc/boot/dts/mpc5121.dtsi | 1 +
drivers/dma/mpc512x_dma.c | 257 ++++++++++++++++++++-
drivers/dma/of-dma.c | 35 +++
include/linux/dmaengine.h | 2 +-
include/linux/of_dma.h | 4 +
6 files changed, 332 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
--
1.8.4.2
^ permalink raw reply
* Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
From: Guenter Roeck @ 2014-05-15 13:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Stephen Rothwell, linuxppc-dev, Alan Modra
In-Reply-To: <1400156571.397.42.camel@pasglop>
On 05/15/2014 05:22 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2014-05-15 at 03:46 -0700, Guenter Roeck wrote:
>> On 05/15/2014 02:47 AM, Alan Modra wrote:
>>> On Wed, May 14, 2014 at 08:34:30AM -0700, Guenter Roeck wrote:
>>>> Bummer. Confirmed, if I replace "@h" with "@high" in just one place,
>>>> the builds pass with binutils 2.24. Unfortunately the same builds then
>>>> fails with binutils 2.23.
>>>>
>>>> Any idea how to get it to compile with both old and new versions ?
>>>
>>> The standard way with GNU software would be to write a configure test,
>>> that checks for @high support in the assembler, and defines a macro
>>> if the assembler passes the check. I'm not that familiar with the
>>> linux kernel these days, but a little grepping around says that
>>> something like
>>>
>>> ashigh := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
>>> KBUILD_AFLAGS += $(ashigh)
>>>
>>> might work.
>>>
>>
>> Yes, it does.
>
> Care to send a patch ? :-)
>
Yes, working on it.
Thanks,
Guenter
^ permalink raw reply
* [PATCH] PPC: ePAPR: Fix hypercall on LE guest
From: Alexander Graf @ 2014-05-15 12:35 UTC (permalink / raw)
To: kvm-ppc; +Cc: scottwood, linuxppc-dev, kvm
We get an array of instructions from the hypervisor via device tree that
we write into a buffer that gets executed whenever we want to make an
ePAPR compliant hypercall.
However, the hypervisor passes us these instructions in BE order which
we have to manually convert to LE when we want to run them in LE mode.
With this fixup in place, I can successfully run LE kernels with KVM
PV enabled on PR KVM.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kernel/epapr_paravirt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/epapr_paravirt.c b/arch/powerpc/kernel/epapr_paravirt.c
index 7898be9..d9b7935 100644
--- a/arch/powerpc/kernel/epapr_paravirt.c
+++ b/arch/powerpc/kernel/epapr_paravirt.c
@@ -47,9 +47,10 @@ static int __init early_init_dt_scan_epapr(unsigned long node,
return -1;
for (i = 0; i < (len / 4); i++) {
- patch_instruction(epapr_hypercall_start + i, insts[i]);
+ u32 inst = be32_to_cpu(insts[i]);
+ patch_instruction(epapr_hypercall_start + i, inst);
#if !defined(CONFIG_64BIT) || defined(CONFIG_PPC_BOOK3E_64)
- patch_instruction(epapr_ev_idle_start + i, insts[i]);
+ patch_instruction(epapr_ev_idle_start + i, inst);
#endif
}
--
1.8.1.4
^ permalink raw reply related
* Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
From: Benjamin Herrenschmidt @ 2014-05-15 12:22 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Stephen Rothwell, linuxppc-dev, Alan Modra
In-Reply-To: <53749B0E.4050900@roeck-us.net>
On Thu, 2014-05-15 at 03:46 -0700, Guenter Roeck wrote:
> On 05/15/2014 02:47 AM, Alan Modra wrote:
> > On Wed, May 14, 2014 at 08:34:30AM -0700, Guenter Roeck wrote:
> >> Bummer. Confirmed, if I replace "@h" with "@high" in just one place,
> >> the builds pass with binutils 2.24. Unfortunately the same builds then
> >> fails with binutils 2.23.
> >>
> >> Any idea how to get it to compile with both old and new versions ?
> >
> > The standard way with GNU software would be to write a configure test,
> > that checks for @high support in the assembler, and defines a macro
> > if the assembler passes the check. I'm not that familiar with the
> > linux kernel these days, but a little grepping around says that
> > something like
> >
> > ashigh := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
> > KBUILD_AFLAGS += $(ashigh)
> >
> > might work.
> >
>
> Yes, it does.
Care to send a patch ? :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
From: Pedro Alves @ 2014-05-15 12:08 UTC (permalink / raw)
To: Anshuman Khandual
Cc: mikey, avagin, linux-kernel, oleg, michael, linuxppc-dev
In-Reply-To: <537479FD.2010200@linux.vnet.ibm.com>
On 05/15/2014 09:25 AM, Anshuman Khandual wrote:
> On 05/14/2014 04:45 PM, Pedro Alves wrote:
>> On 05/14/14 06:46, Anshuman Khandual wrote:
>>> On 05/13/2014 10:43 PM, Pedro Alves wrote:
>>>> On 05/05/14 08:54, Anshuman Khandual wrote:
>>>>> This patch enables get and set of transactional memory related register
>>>>> sets through PTRACE_GETREGSET/PTRACE_SETREGSET interface by implementing
>>>>> four new powerpc specific register sets i.e REGSET_TM_SPR, REGSET_TM_CGPR,
>>>>> REGSET_TM_CFPR, REGSET_CVMX support corresponding to these following new
>>>>> ELF core note types added previously in this regard.
>>>>>
>>>>> (1) NT_PPC_TM_SPR
>>>>> (2) NT_PPC_TM_CGPR
>>>>> (3) NT_PPC_TM_CFPR
>>>>> (4) NT_PPC_TM_CVMX
>>>>
>>>> Sorry that I couldn't tell this from the code, but, what does the
>>>> kernel return when the ptracer requests these registers and the
>>>> program is not in a transaction? Specifically I'm wondering whether
>>>> this follows the same semantics as the s390 port.
>>>>
>>>
>>> Right now, it still returns the saved state of the registers from thread
>>> struct. I had assumed that the user must know the state of the transaction
>>> before initiating the ptrace request. I guess its better to check for
>>> the transaction status before processing the request. In case if TM is not
>>> active on that thread, we should return -EINVAL.
>>
>> I think s390 returns ENODATA in that case.
>>
>> https://sourceware.org/ml/gdb-patches/2013-06/msg00273.html
>>
>> We'll want some way to tell whether the system actually
>> supports this. That could be ENODATA vs something-else (EINVAL
>> or perhaps better EIO for "request is invalid").
>
> As Mickey has pointed out, the transaction memory support in the system can be
> checked from the HWCAP2 flags. So when the transaction is not active, we will
> return ENODATA instead for TM related ptrace regset requests.
Returning ENODATA when the transaction is not active, like
s390 is great. Thank you.
But I think it's worth it to consider what should the kernel
return when the machine doesn't have these registers at all.
Sure, for this case we happen to have the hwcap flag. But in
general, I don't know whether we will always have a hwcap bit
for each register set that is added. Maybe we will, so that
the info ends up in core dumps.
Still, I think it's worth to consider this case in the
general sense, irrespective of hwcap.
That is, what should PTRACE_GETREGSET/PTRACE_SETREGSET return
when the machine doesn't have the registers at all. We shouldn't
need to consult something elsewhere (like hwcap) to determine
what ENODATA means. The kernel knows it right there. I think
s390 goofed here.
Taking a look at x86, for example, we see:
[REGSET_XSTATE] = {
.core_note_type = NT_X86_XSTATE,
.size = sizeof(u64), .align = sizeof(u64),
.active = xstateregs_active, .get = xstateregs_get,
.set = xstateregs_set
},
Note that it installs the ".active" hook.
24 /**
25 * user_regset_active_fn - type of @active function in &struct user_regset
26 * @target: thread being examined
27 * @regset: regset being examined
28 *
29 * Return -%ENODEV if not available on the hardware found.
30 * Return %0 if no interesting state in this thread.
31 * Return >%0 number of @size units of interesting state.
32 * Any get call fetching state beyond that number will
33 * see the default initialization state for this data,
34 * so a caller that knows what the default state is need
35 * not copy it all out.
36 * This call is optional; the pointer is %NULL if there
37 * is no inexpensive check to yield a value < @n.
38 */
39 typedef int user_regset_active_fn(struct task_struct *target,
40 const struct user_regset *regset);
41
Note the mention of ENODEV.
I couldn't actually find any arch that currently returns -ENODEV in
the "active" hook. I see that binfmt_elf.c doesn't handle
regset->active() returning < 0. Guess that may be why. Looks like
something that could be cleaned up, to me.
Anyway, notice x86's REGSET_XSTATE regset->get hook:
int xstateregs_get(struct task_struct *target, const struct user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
{
int ret;
if (!cpu_has_xsave)
return -ENODEV;
^^^^^^^^^^^^^^^^^^^^^^
And then we see that xfpregs_get has a similar ENODEV case.
So in sum, it very much looks like the intention is for
PTRACE_GETREGSET/PTRACE_SETREGSET to return ENODEV in the
case the regset doesn't exist on the running machine, and then
it looks like at least x86 works that way.
--
Pedro Alves
^ permalink raw reply
* Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
From: Guenter Roeck @ 2014-05-15 10:46 UTC (permalink / raw)
To: Alan Modra; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20140515094716.GQ5162@bubble.grove.modra.org>
On 05/15/2014 02:47 AM, Alan Modra wrote:
> On Wed, May 14, 2014 at 08:34:30AM -0700, Guenter Roeck wrote:
>> Bummer. Confirmed, if I replace "@h" with "@high" in just one place,
>> the builds pass with binutils 2.24. Unfortunately the same builds then
>> fails with binutils 2.23.
>>
>> Any idea how to get it to compile with both old and new versions ?
>
> The standard way with GNU software would be to write a configure test,
> that checks for @high support in the assembler, and defines a macro
> if the assembler passes the check. I'm not that familiar with the
> linux kernel these days, but a little grepping around says that
> something like
>
> ashigh := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
> KBUILD_AFLAGS += $(ashigh)
>
> might work.
>
Yes, it does.
Thanks!
Guenter
^ permalink raw reply
* Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
From: Alan Modra @ 2014-05-15 9:47 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20140514153430.GA28553@roeck-us.net>
On Wed, May 14, 2014 at 08:34:30AM -0700, Guenter Roeck wrote:
> Bummer. Confirmed, if I replace "@h" with "@high" in just one place,
> the builds pass with binutils 2.24. Unfortunately the same builds then
> fails with binutils 2.23.
>
> Any idea how to get it to compile with both old and new versions ?
The standard way with GNU software would be to write a configure test,
that checks for @high support in the assembler, and defines a macro
if the assembler passes the check. I'm not that familiar with the
linux kernel these days, but a little grepping around says that
something like
ashigh := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
KBUILD_AFLAGS += $(ashigh)
might work.
> Is there some predefined constant which I could possibly use for
> something like
>
> .if as_version_below_2.24_
> oris reg,reg,(expr)@h;
> .else
> oris reg,reg,(expr)@high;
> .endif
>
> Thanks,
> Guenter
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
From: Anshuman Khandual @ 2014-05-15 8:25 UTC (permalink / raw)
To: Pedro Alves; +Cc: mikey, avagin, linux-kernel, oleg, michael, linuxppc-dev
In-Reply-To: <53735044.5030008@redhat.com>
On 05/14/2014 04:45 PM, Pedro Alves wrote:
> On 05/14/14 06:46, Anshuman Khandual wrote:
>> On 05/13/2014 10:43 PM, Pedro Alves wrote:
>>> On 05/05/14 08:54, Anshuman Khandual wrote:
>>>> This patch enables get and set of transactional memory related register
>>>> sets through PTRACE_GETREGSET/PTRACE_SETREGSET interface by implementing
>>>> four new powerpc specific register sets i.e REGSET_TM_SPR, REGSET_TM_CGPR,
>>>> REGSET_TM_CFPR, REGSET_CVMX support corresponding to these following new
>>>> ELF core note types added previously in this regard.
>>>>
>>>> (1) NT_PPC_TM_SPR
>>>> (2) NT_PPC_TM_CGPR
>>>> (3) NT_PPC_TM_CFPR
>>>> (4) NT_PPC_TM_CVMX
>>>
>>> Sorry that I couldn't tell this from the code, but, what does the
>>> kernel return when the ptracer requests these registers and the
>>> program is not in a transaction? Specifically I'm wondering whether
>>> this follows the same semantics as the s390 port.
>>>
>>
>> Right now, it still returns the saved state of the registers from thread
>> struct. I had assumed that the user must know the state of the transaction
>> before initiating the ptrace request. I guess its better to check for
>> the transaction status before processing the request. In case if TM is not
>> active on that thread, we should return -EINVAL.
>
> I think s390 returns ENODATA in that case.
>
> https://sourceware.org/ml/gdb-patches/2013-06/msg00273.html
>
> We'll want some way to tell whether the system actually
> supports this. That could be ENODATA vs something-else (EINVAL
> or perhaps better EIO for "request is invalid").
As Mickey has pointed out, the transaction memory support in the system can be
checked from the HWCAP2 flags. So when the transaction is not active, we will
return ENODATA instead for TM related ptrace regset requests.
^ permalink raw reply
* Re: [PATCH V4 0/2] mm: FAULT_AROUND_ORDER patchset performance data for powerpc
From: Madhavan Srinivasan @ 2014-05-15 8:25 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, linux-mm, linux-arch, x86
Cc: riel, ak, peterz, rusty, dave.hansen, paulus, mgorman, akpm,
mingo, kirill.shutemov
In-Reply-To: <1399541296-18810-1-git-send-email-maddy@linux.vnet.ibm.com>
Hi Ingo,
Do you have any comments for the latest version of the patchset. If
not, kindly can you pick it up as is.
With regards
Maddy
> Kirill A. Shutemov with 8c6e50b029 commit introduced
> vm_ops->map_pages() for mapping easy accessible pages around
> fault address in hope to reduce number of minor page faults.
>
> This patch creates infrastructure to modify the FAULT_AROUND_ORDER
> value using mm/Kconfig. This will enable architecture maintainers
> to decide on suitable FAULT_AROUND_ORDER value based on
> performance data for that architecture. First patch also defaults
> FAULT_AROUND_ORDER Kconfig element to 4. Second patch list
> out the performance numbers for powerpc (platform pseries) and
> initialize the fault around order variable for pseries platform of
> powerpc.
>
> V4 Changes:
> Replaced the BUILD_BUG_ON with VM_BUG_ON.
> Moved fault_around_pages() and fault_around_mask() functions outside of
> #ifdef CONFIG_DEBUG_FS.
>
> V3 Changes:
> Replaced FAULT_AROUND_ORDER macro to a variable to support arch's that
> supports sub platforms.
> Made changes in commit messages.
>
> V2 Changes:
> Created Kconfig parameter for FAULT_AROUND_ORDER
> Added check in do_read_fault to handle FAULT_AROUND_ORDER value of 0
> Made changes in commit messages.
>
> Madhavan Srinivasan (2):
> mm: move FAULT_AROUND_ORDER to arch/
> powerpc/pseries: init fault_around_order for pseries
>
> arch/powerpc/platforms/pseries/pseries.h | 2 ++
> arch/powerpc/platforms/pseries/setup.c | 5 +++++
> mm/Kconfig | 8 ++++++++
> mm/memory.c | 25 ++++++-------------------
> 4 files changed, 21 insertions(+), 19 deletions(-)
>
^ permalink raw reply
* [PATCH][v2] powerpc/mpc85xx: Add BSC9132 QDS Support
From: Harninder Rai @ 2014-05-15 7:45 UTC (permalink / raw)
To: scottwood; +Cc: Harninder Rai, linuxppc-dev, Ruchika Gupta
- BSC9132 is an integrated device that targets Femto base station market.
It combines Power Architecture e500v2 and DSP StarCore SC3850 technologies
with MAPLE-B2F baseband acceleration processing elements
- BSC9132QDS Overview
2Gbyte DDR3 (on board DDR)
32Mbyte 16bit NOR flash
128Mbyte 2K page size NAND Flash
256 Kbit M24256 I2C EEPROM
128 Mbit SPI Flash memory
SD slot
eTSEC1: Connected to SGMII PHY
eTSEC2: Connected to SGMII PHY
DUART interface: supports one UARTs up to 115200 bps for console display
Signed-off-by: Harninder Rai <harninder.rai@freescale.com>
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
---
Changes since base version:
Incorporated Scott's comment
- Remove flash partition information from device tree
.../devicetree/bindings/powerpc/fsl/board.txt | 17 ++
arch/powerpc/boot/dts/bsc9132qds.dts | 35 ++++
arch/powerpc/boot/dts/bsc9132qds.dtsi | 101 +++++++++++
arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi | 185 ++++++++++++++++++++
arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi | 66 +++++++
arch/powerpc/platforms/85xx/Kconfig | 9 +
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/bsc913x_qds.c | 74 ++++++++
8 files changed, 488 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/bsc9132qds.dts
create mode 100644 arch/powerpc/boot/dts/bsc9132qds.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
create mode 100644 arch/powerpc/platforms/85xx/bsc913x_qds.c
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
index 380914e..700dec4 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
@@ -67,3 +67,20 @@ Example:
gpio-controller;
};
};
+
+* Freescale on-board FPGA connected on I2C bus
+
+Some Freescale boards like BSC9132QDS have on board FPGA connected on
+the i2c bus.
+
+Required properties:
+- compatible: Should be a board-specific string followed by a string
+ indicating the type of FPGA. Example:
+ "fsl,<board>-fpga", "fsl,fpga-qixis-i2c"
+- reg: Should contain the address of the FPGA
+
+Example:
+ fpga: fpga@66 {
+ compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c";
+ reg = <0x66>;
+ };
diff --git a/arch/powerpc/boot/dts/bsc9132qds.dts b/arch/powerpc/boot/dts/bsc9132qds.dts
new file mode 100644
index 0000000..6cab106
--- /dev/null
+++ b/arch/powerpc/boot/dts/bsc9132qds.dts
@@ -0,0 +1,35 @@
+/*
+ * BSC9132 QDS Device Tree Source
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/include/ "fsl/bsc9132si-pre.dtsi"
+
+/ {
+ model = "fsl,bsc9132qds";
+ compatible = "fsl,bsc9132qds";
+
+ memory {
+ device_type = "memory";
+ };
+
+ ifc: ifc@ff71e000 {
+ /* NOR, NAND Flash on board */
+ ranges = <0x0 0x0 0x0 0x88000000 0x08000000
+ 0x1 0x0 0x0 0xff800000 0x00010000>;
+ reg = <0x0 0xff71e000 0x0 0x2000>;
+ };
+
+ soc: soc@ff700000 {
+ ranges = <0x0 0x0 0xff700000 0x100000>;
+ };
+};
+
+/include/ "bsc9132qds.dtsi"
+/include/ "fsl/bsc9132si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/bsc9132qds.dtsi b/arch/powerpc/boot/dts/bsc9132qds.dtsi
new file mode 100644
index 0000000..af8e888
--- /dev/null
+++ b/arch/powerpc/boot/dts/bsc9132qds.dtsi
@@ -0,0 +1,101 @@
+/*
+ * BSC9132 QDS Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * 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.
+ */
+
+&ifc {
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ nand@1,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc-nand";
+ reg = <0x1 0x0 0x4000>;
+ };
+};
+
+&soc {
+ spi@7000 {
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25sl12801";
+ reg = <0>;
+ spi-max-frequency = <30000000>;
+ };
+ };
+
+ i2c@3000 {
+ fpga: fpga@66 {
+ compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c";
+ reg = <0x66>;
+ };
+ };
+
+ usb@22000 {
+ phy_type = "ulpi";
+ };
+
+ mdio@24000 {
+ phy0: ethernet-phy@0 {
+ reg = <0x0>;
+ };
+
+ phy1: ethernet-phy@1 {
+ reg = <0x1>;
+ };
+
+ tbi0: tbi-phy@11 {
+ reg = <0x1f>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ enet0: ethernet@b0000 {
+ phy-handle = <&phy0>;
+ tbi-handle = <&tbi0>;
+ phy-connection-type = "sgmii";
+ };
+
+ enet1: ethernet@b1000 {
+ phy-handle = <&phy1>;
+ tbi-handle = <&tbi0>;
+ phy-connection-type = "sgmii";
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi b/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
new file mode 100644
index 0000000..c723071
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
@@ -0,0 +1,185 @@
+/*
+ * BSC9132 Silicon/SoC Device Tree Source (post include)
+ *
+ * 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.
+ */
+
+&ifc {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc", "simple-bus";
+ /* FIXME: Test whether interrupts are split */
+ interrupts = <16 2 0 0 20 2 0 0>;
+};
+
+&soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,bsc9132-immr", "simple-bus";
+ bus-frequency = <0>; // Filled out by uboot.
+
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <12>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,bsc9132-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <16 2 0 0>;
+ };
+
+ memory-controller@2000 {
+ compatible = "fsl,bsc9132-memory-controller";
+ reg = <0x2000 0x1000>;
+ interrupts = <16 2 1 8>;
+ };
+
+/include/ "pq3-i2c-0.dtsi"
+ i2c@3000 {
+ interrupts = <17 2 0 0>;
+ };
+
+/include/ "pq3-i2c-1.dtsi"
+ i2c@3100 {
+ interrupts = <17 2 0 0>;
+ };
+
+/include/ "pq3-duart-0.dtsi"
+ serial0: serial@4500 {
+ interrupts = <18 2 0 0>;
+ };
+
+ serial1: serial@4600 {
+ interrupts = <18 2 0 0 >;
+ };
+/include/ "pq3-espi-0.dtsi"
+ spi0: spi@7000 {
+ fsl,espi-num-chipselects = <1>;
+ interrupts = <22 0x2 0 0>;
+ };
+
+/include/ "pq3-gpio-0.dtsi"
+ gpio-controller@f000 {
+ interrupts = <19 0x2 0 0>;
+ };
+
+ L2: l2-cache-controller@20000 {
+ compatible = "fsl,bsc9132-l2-cache-controller";
+ reg = <0x20000 0x1000>;
+ cache-line-size = <32>; // 32 bytes
+ cache-size = <0x40000>; // L2,256K
+ interrupts = <16 2 1 0>;
+ };
+
+/include/ "pq3-dma-0.dtsi"
+
+dma@21300 {
+
+ dma-channel@0 {
+ interrupts = <62 2 0 0>;
+ };
+
+ dma-channel@80 {
+ interrupts = <63 2 0 0>;
+ };
+
+ dma-channel@100 {
+ interrupts = <64 2 0 0>;
+ };
+
+ dma-channel@180 {
+ interrupts = <65 2 0 0>;
+ };
+};
+
+/include/ "pq3-usb2-dr-0.dtsi"
+usb@22000 {
+ compatible = "fsl-usb2-dr","fsl-usb2-dr-v2.2";
+ interrupts = <40 0x2 0 0>;
+};
+
+/include/ "pq3-esdhc-0.dtsi"
+ sdhc@2e000 {
+ fsl,sdhci-auto-cmd12;
+ interrupts = <41 0x2 0 0>;
+ };
+
+/include/ "pq3-sec4.4-0.dtsi"
+crypto@30000 {
+ interrupts = <57 2 0 0>;
+
+ sec_jr0: jr@1000 {
+ interrupts = <58 2 0 0>;
+ };
+
+ sec_jr1: jr@2000 {
+ interrupts = <59 2 0 0>;
+ };
+
+ sec_jr2: jr@3000 {
+ interrupts = <60 2 0 0>;
+ };
+
+ sec_jr3: jr@4000 {
+ interrupts = <61 2 0 0>;
+ };
+};
+
+/include/ "pq3-mpic.dtsi"
+/include/ "pq3-mpic-timer-B.dtsi"
+
+/include/ "pq3-etsec2-0.dtsi"
+enet0: ethernet@b0000 {
+ queue-group@b0000 {
+ fsl,rx-bit-map = <0xff>;
+ fsl,tx-bit-map = <0xff>;
+ interrupts = <26 2 0 0 27 2 0 0 28 2 0 0>;
+ };
+};
+
+/include/ "pq3-etsec2-1.dtsi"
+enet1: ethernet@b1000 {
+ queue-group@b1000 {
+ fsl,rx-bit-map = <0xff>;
+ fsl,tx-bit-map = <0xff>;
+ interrupts = <33 2 0 0 34 2 0 0 35 2 0 0>;
+ };
+};
+
+global-utilities@e0000 {
+ compatible = "fsl,bsc9132-guts";
+ reg = <0xe0000 0x1000>;
+ fsl,has-rstcr;
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi b/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
new file mode 100644
index 0000000..301a9db
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
@@ -0,0 +1,66 @@
+/*
+ * BSC9132 Silicon/SoC Device Tree Source (pre include)
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+/include/ "e500v2_power_isa.dtsi"
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ aliases {
+ serial0 = &serial0;
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: PowerPC,e500v2@0 {
+ device_type = "cpu";
+ reg = <0x0>;
+ next-level-cache = <&L2>;
+ };
+
+ cpu1: PowerPC,e500v2@1 {
+ device_type = "cpu";
+ reg = <0x1>;
+ next-level-cache = <&L2>;
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index c17aae8..4bd7223 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -38,6 +38,15 @@ config C293_PCIE
help
This option enables support for the C293PCIE board
+config BSC9132_QDS
+ bool "Freescale BSC9132QDS"
+ select DEFAULT_UIMAGE
+ help
+ This option enables support for the Freescale BSC9132 QDS board.
+ BSC9132 is a heterogeneous SoC containing dual e500v2 powerpc cores
+ and dual StarCore SC3850 DSP cores.
+ Manufacturer : Freescale Semiconductor, Inc
+
config MPC8540_ADS
bool "Freescale MPC8540 ADS"
select DEFAULT_UIMAGE
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 25cebe7..c19beb9 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_SMP) += smp.o
obj-y += common.o
obj-$(CONFIG_BSC9131_RDB) += bsc913x_rdb.o
+obj-$(CONFIG_BSC9132_QDS) += bsc913x_qds.o
obj-$(CONFIG_C293_PCIE) += c293pcie.o
obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o
obj-$(CONFIG_MPC8560_ADS) += mpc85xx_ads.o
diff --git a/arch/powerpc/platforms/85xx/bsc913x_qds.c b/arch/powerpc/platforms/85xx/bsc913x_qds.c
new file mode 100644
index 0000000..f0927e5
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/bsc913x_qds.c
@@ -0,0 +1,74 @@
+/*
+ * BSC913xQDS Board Setup
+ *
+ * Author:
+ * Harninder Rai <harninder.rai@freescale.com>
+ * Priyanka Jain <Priyanka.Jain@freescale.com>
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <asm/mpic.h>
+#include <sysdev/fsl_soc.h>
+#include <asm/udbg.h>
+
+#include "mpc85xx.h"
+#include "smp.h"
+
+void __init bsc913x_qds_pic_init(void)
+{
+ struct mpic *mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN |
+ MPIC_SINGLE_DEST_CPU,
+ 0, 256, " OpenPIC ");
+
+ if (!mpic)
+ pr_err("bsc913x: Failed to allocate MPIC structure\n");
+ else
+ mpic_init(mpic);
+}
+
+/*
+ * Setup the architecture
+ */
+static void __init bsc913x_qds_setup_arch(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress("bsc913x_qds_setup_arch()", 0);
+
+#if defined(CONFIG_SMP)
+ mpc85xx_smp_init();
+#endif
+
+ pr_info("bsc913x board from Freescale Semiconductor\n");
+}
+
+machine_device_initcall(bsc9132_qds, mpc85xx_common_publish_devices);
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+
+static int __init bsc9132_qds_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "fsl,bsc9132qds");
+}
+
+define_machine(bsc9132_qds) {
+ .name = "BSC9132 QDS",
+ .probe = bsc9132_qds_probe,
+ .setup_arch = bsc913x_qds_setup_arch,
+ .init_IRQ = bsc913x_qds_pic_init,
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.7.6.GIT
^ permalink raw reply related
* Re: [PATCH RFC v3 0/8] EEH Support for VFIO PCI device
From: Gavin Shan @ 2014-05-15 7:43 UTC (permalink / raw)
To: Mike Qiu; +Cc: aik, Gavin Shan, kvm-ppc, agraf, alex.williamson, linuxppc-dev
In-Reply-To: <53745FF3.6050102@linux.vnet.ibm.com>
On Thu, May 15, 2014 at 02:34:27PM +0800, Mike Qiu wrote:
>Hi Gavin,
>
>Can error injection be done if EEH is not enbaled?
>
Yes, utility "errinject" still can inject PCI errors to host for
testing purpose. Since the PCI errors injected by "errinjct" is
mainly for EEH testing. it would be meaningless to do PCI error
injection without EEH support. So for the case, the hooks doing
real work is being protected by CONFIG_EEH.
The hooks for another case (error injection from "errinject"
utility running on guest) are protected by CONFIG_EEH_VFIO
Thanks,
Gavin
>On 05/14/2014 12:11 PM, Gavin Shan wrote:
>>The series of patches intends to support EEH for PCI devices, which are
>>passed through to PowerKVM based guest via VFIO. The implementation is
>>straightforward based on the issues or problems we have to resolve to
>>support EEH for PowerKVM based guest.
>>
>>- Emulation for EEH RTAS requests. All EEH RTAS requests goes to QEMU firstly.
>> If QEMU can't handle it, the request will be sent to host via newly introduced
>> VFIO container IOCTL command (VFIO_EEH_INFO) and gets handled in host kernel.
>>
>>- The error injection infrastructure need support request from the userland
>> utility "errinjct" and PowerKVM based guest. The userland utility "errinjct"
>> works on pSeries platform well with dedicated syscall, which helps invoking
>> RTAS service to fulfil error injection in kernel. From the perspective, it's
>> reasonable to extend the syscall to support PowerNV platform so that OPAL call
>> can be invoked in host kernel for injecting errors. The data transported
>> between userland and kerenl is still following "struct rtas_args" for both
>> cases of PowerNV (OPAL) and pSeries (RTAS).
>>
>>The series of patches requires corresponding firmware changes from Mike Qiu to
>>support error injection and QEMU changes to support EEH for guest. QEMU patchset
>>will be sent separately.
>>
>>Change log
>>==========
>>v1 -> v2:
>> * EEH RTAS requests are routed to QEMU, and then possiblly to host kerenl.
>> The mechanism KVM in-kernel handling is dropped.
>> * Error injection is reimplemented based syscall, instead of KVM in-kerenl
>> handling. The logic for error injection token management is moved to
>> QEMU. The error injection request is routed to QEMU and then possiblly
>> to host kernel.
>>v2 -> v3:
>> * Make the fields in struct eeh_vfio_pci_addr, struct vfio_eeh_info based
>> on the comments from Alexey.
>> * Define macros for EEH VFIO operations (Alexey).
>> * Clear frozen state after successful PE reset.
>> * Merge original [PATCH 1/2/3] to one.
>>
>>Testing on P7
>>=============
>>
>>- Emulex adapter
>>
>>Testing on P8
>>=============
>>
>>- Need more testing after design is finalized.
>>
>>-----
>>
>>Gavin Shan (8):
>> drivers/vfio: Introduce CONFIG_VFIO_EEH
>> powerpc/eeh: Info to trace passed devices
>> drivers/vfio: New IOCTL command VFIO_EEH_INFO
>> powerpc/eeh: Avoid event on passed PE
>> powerpc/powernv: Sync OPAL header file with firmware
>> powerpc: Extend syscall ppc_rtas()
>> powerpc/powernv: Implement ppc_call_opal()
>> powerpc/powernv: Error injection infrastructure
>>
>> arch/powerpc/include/asm/eeh.h | 52 +++
>> arch/powerpc/include/asm/opal.h | 74 ++-
>> arch/powerpc/include/asm/rtas.h | 10 +-
>> arch/powerpc/include/asm/syscalls.h | 2 +-
>> arch/powerpc/include/asm/systbl.h | 2 +-
>> arch/powerpc/include/uapi/asm/unistd.h | 2 +-
>> arch/powerpc/kernel/eeh.c | 8 +
>> arch/powerpc/kernel/eeh_pe.c | 80 ++++
>> arch/powerpc/kernel/rtas.c | 57 +--
>> arch/powerpc/kernel/syscalls.c | 50 +++
>> arch/powerpc/platforms/powernv/Makefile | 3 +-
>> arch/powerpc/platforms/powernv/eeh-ioda.c | 3 +-
>> arch/powerpc/platforms/powernv/eeh-vfio.c | 593 +++++++++++++++++++++++++
>> arch/powerpc/platforms/powernv/errinject.c | 224 ++++++++++
>> arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
>> arch/powerpc/platforms/powernv/opal.c | 93 ++++
>> drivers/vfio/Kconfig | 6 +
>> drivers/vfio/vfio_iommu_spapr_tce.c | 12 +
>> include/uapi/linux/vfio.h | 57 +++
>> kernel/sys_ni.c | 2 +-
>> 20 files changed, 1278 insertions(+), 53 deletions(-)
>> create mode 100644 arch/powerpc/platforms/powernv/eeh-vfio.c
>> create mode 100644 arch/powerpc/platforms/powernv/errinject.c
>>
>>Thanks,
>>Gavin
>>
>
^ permalink raw reply
* Re: [PATCH RFC v3 0/8] EEH Support for VFIO PCI device
From: Mike Qiu @ 2014-05-15 6:34 UTC (permalink / raw)
To: Gavin Shan; +Cc: aik, agraf, kvm-ppc, alex.williamson, linuxppc-dev
In-Reply-To: <1400040722-29608-1-git-send-email-gwshan@linux.vnet.ibm.com>
Hi Gavin,
Can error injection be done if EEH is not enbaled?
Thanks
Mike
On 05/14/2014 12:11 PM, Gavin Shan wrote:
> The series of patches intends to support EEH for PCI devices, which are
> passed through to PowerKVM based guest via VFIO. The implementation is
> straightforward based on the issues or problems we have to resolve to
> support EEH for PowerKVM based guest.
>
> - Emulation for EEH RTAS requests. All EEH RTAS requests goes to QEMU firstly.
> If QEMU can't handle it, the request will be sent to host via newly introduced
> VFIO container IOCTL command (VFIO_EEH_INFO) and gets handled in host kernel.
>
> - The error injection infrastructure need support request from the userland
> utility "errinjct" and PowerKVM based guest. The userland utility "errinjct"
> works on pSeries platform well with dedicated syscall, which helps invoking
> RTAS service to fulfil error injection in kernel. From the perspective, it's
> reasonable to extend the syscall to support PowerNV platform so that OPAL call
> can be invoked in host kernel for injecting errors. The data transported
> between userland and kerenl is still following "struct rtas_args" for both
> cases of PowerNV (OPAL) and pSeries (RTAS).
>
> The series of patches requires corresponding firmware changes from Mike Qiu to
> support error injection and QEMU changes to support EEH for guest. QEMU patchset
> will be sent separately.
>
> Change log
> ==========
> v1 -> v2:
> * EEH RTAS requests are routed to QEMU, and then possiblly to host kerenl.
> The mechanism KVM in-kernel handling is dropped.
> * Error injection is reimplemented based syscall, instead of KVM in-kerenl
> handling. The logic for error injection token management is moved to
> QEMU. The error injection request is routed to QEMU and then possiblly
> to host kernel.
> v2 -> v3:
> * Make the fields in struct eeh_vfio_pci_addr, struct vfio_eeh_info based
> on the comments from Alexey.
> * Define macros for EEH VFIO operations (Alexey).
> * Clear frozen state after successful PE reset.
> * Merge original [PATCH 1/2/3] to one.
>
> Testing on P7
> =============
>
> - Emulex adapter
>
> Testing on P8
> =============
>
> - Need more testing after design is finalized.
>
> -----
>
> Gavin Shan (8):
> drivers/vfio: Introduce CONFIG_VFIO_EEH
> powerpc/eeh: Info to trace passed devices
> drivers/vfio: New IOCTL command VFIO_EEH_INFO
> powerpc/eeh: Avoid event on passed PE
> powerpc/powernv: Sync OPAL header file with firmware
> powerpc: Extend syscall ppc_rtas()
> powerpc/powernv: Implement ppc_call_opal()
> powerpc/powernv: Error injection infrastructure
>
> arch/powerpc/include/asm/eeh.h | 52 +++
> arch/powerpc/include/asm/opal.h | 74 ++-
> arch/powerpc/include/asm/rtas.h | 10 +-
> arch/powerpc/include/asm/syscalls.h | 2 +-
> arch/powerpc/include/asm/systbl.h | 2 +-
> arch/powerpc/include/uapi/asm/unistd.h | 2 +-
> arch/powerpc/kernel/eeh.c | 8 +
> arch/powerpc/kernel/eeh_pe.c | 80 ++++
> arch/powerpc/kernel/rtas.c | 57 +--
> arch/powerpc/kernel/syscalls.c | 50 +++
> arch/powerpc/platforms/powernv/Makefile | 3 +-
> arch/powerpc/platforms/powernv/eeh-ioda.c | 3 +-
> arch/powerpc/platforms/powernv/eeh-vfio.c | 593 +++++++++++++++++++++++++
> arch/powerpc/platforms/powernv/errinject.c | 224 ++++++++++
> arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
> arch/powerpc/platforms/powernv/opal.c | 93 ++++
> drivers/vfio/Kconfig | 6 +
> drivers/vfio/vfio_iommu_spapr_tce.c | 12 +
> include/uapi/linux/vfio.h | 57 +++
> kernel/sys_ni.c | 2 +-
> 20 files changed, 1278 insertions(+), 53 deletions(-)
> create mode 100644 arch/powerpc/platforms/powernv/eeh-vfio.c
> create mode 100644 arch/powerpc/platforms/powernv/errinject.c
>
> Thanks,
> Gavin
>
^ permalink raw reply
* roundup_pow_of_two() may not handle 64-bit integers
From: Brian Norris @ 2014-05-15 2:22 UTC (permalink / raw)
To: Linux Kernel
Cc: David Howells, Paul Mackerras, Andrew Morton, Brian Norris,
linuxppc-dev
Hi,
I'm looking to use roundup_pow_of_two() (actually, order_base_2())
from <linux/log2.h>, but it seems that it only supports 64-bit integers
if your toolchain uses a 64-bit 'unsigned long' type. This is strange,
considering that ilog2() is explicitly designed for 32-bit or 64-bit
compatibility.
I also note that there is at least one location in which this limitation
currently might be problematic: in pnv_pci_ioda2_set_bypass()
(arch/powerpc/platforms/powernv/pci-ioda.c). It looks like this could be
a problem if using large amounts of DRAM on a 32-bit PPC build, with
64-bit physical addresses.
(There may be other cases like this one, but I haven't closely studied
all callers of roundup_pow_of_two().)
I'm thinking of cooking a patch to improve roundup_pow_of_two() (and
thus order_base_2()), but I'd like to solicit comments on the basic
problem first.
Regards,
Brian
P.S. And of course, rounddown_pow_of_two() has the same issue.
^ permalink raw reply
* [PATCH 20/27] powerpc: Use common bits from generic tlb.h
From: Richard Weinberger @ 2014-05-14 18:59 UTC (permalink / raw)
To: linux-arch, arnd, linux-kernel
Cc: Richard Weinberger, Paul Mackerras, linuxppc-dev
In-Reply-To: <1400093999-18703-1-git-send-email-richard@nod.at>
It is no longer needed to define them on our own.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Richard Weinberger <richard@nod.at>
---
arch/powerpc/include/asm/tlb.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/include/asm/tlb.h b/arch/powerpc/include/asm/tlb.h
index 392e5ef..bdea7f5 100644
--- a/arch/powerpc/include/asm/tlb.h
+++ b/arch/powerpc/include/asm/tlb.h
@@ -25,9 +25,6 @@
#include <linux/pagemap.h>
-#define tlb_start_vma(tlb, vma) do { } while (0)
-#define tlb_end_vma(tlb, vma) do { } while (0)
-
extern void tlb_flush(struct mmu_gather *tlb);
/* These defines are needed to override the defaults from asm-generic/tlb.h */
--
1.8.4.2
^ permalink raw reply related
* [PATCH 02/27] powerpc: Override defaults from generic/tlb.h
From: Richard Weinberger @ 2014-05-14 18:59 UTC (permalink / raw)
To: linux-arch, arnd, linux-kernel
Cc: Richard Weinberger, Paul Mackerras, linuxppc-dev
In-Reply-To: <1400093999-18703-1-git-send-email-richard@nod.at>
Make sure to not conflict with the defaults provided
by generic/tlb.h.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Richard Weinberger <richard@nod.at>
---
arch/powerpc/include/asm/pgalloc.h | 1 -
arch/powerpc/include/asm/tlb.h | 4 ++++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/pgalloc.h b/arch/powerpc/include/asm/pgalloc.h
index e9a9f60..5fddba7 100644
--- a/arch/powerpc/include/asm/pgalloc.h
+++ b/arch/powerpc/include/asm/pgalloc.h
@@ -3,7 +3,6 @@
#ifdef __KERNEL__
#include <linux/mm.h>
-#include <asm-generic/tlb.h>
#ifdef CONFIG_PPC_BOOK3E
extern void tlb_flush_pgtable(struct mmu_gather *tlb, unsigned long address);
diff --git a/arch/powerpc/include/asm/tlb.h b/arch/powerpc/include/asm/tlb.h
index e2b428b..392e5ef 100644
--- a/arch/powerpc/include/asm/tlb.h
+++ b/arch/powerpc/include/asm/tlb.h
@@ -30,6 +30,10 @@
extern void tlb_flush(struct mmu_gather *tlb);
+/* These defines are needed to override the defaults from asm-generic/tlb.h */
+#define tlb_flush tlb_flush
+#define __tlb_remove_tlb_entry __tlb_remove_tlb_entry
+
/* Get the generic bits... */
#include <asm-generic/tlb.h>
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH v2] powerpc: Add cpu family documentation
From: James Yang @ 2014-05-14 18:04 UTC (permalink / raw)
To: Scott Wood; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <1398882547.24575.211.camel@snotra.buserror.net>
On Wed, 30 Apr 2014, Scott Wood wrote:
> On Wed, 2014-04-30 at 16:45 +1000, Michael Ellerman wrote:
> > On Tue, 2014-02-04 at 16:43 -0600, Scott Wood wrote:
> > > > +Motorola/Freescale 8xx
> > > > +----------------------
> > > > +
> > > > + - Software loaded with hardware assist.
> > > > + - All 32 bit
> > > > +
> > > > + +--------------+
> > > > + | 8xx |
> > > > + +--------------+
> > > > + |
> > > > + |
> > > > + v
> > > > + +--------------+
> > > > + | 850 |
> > > > + +--------------+
> > >
> > > Is the core of MPC850 different from other MPC8xx?
> >
> > Dunno, maybe someone who works at Freescale knows ;)
>
> I think they're the same -- I was just wondering if you had some
> difference in mind that led you to single it out.
They are the same.
There should not be a separate box that singles out 850. (Still don't
know why the diagram was drawn to single out 850 in the first place.)
The CPU core should be called "MPC8xx Core".
^ 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