* 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
* [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: 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 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
* [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 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 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 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 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
* 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
* 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
* [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
* [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] powerpc: Fix unused variable warning for epapr_has_idle
From: Scott Wood @ 2014-05-15 16:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
This warning can be seen in allyesconfig, and was introduced by commit
f9eb581c63b2acce827570e105205c0789360650 "powerpc: fix build of
epapr_paravirt on 64-bit book3s".
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
Sorry about the churn on this -- I did try to build allyesconfig, but I
forgot that CONFIG_PPC_DISABLE_WERROR would be enabled, plus the build
failed on the "attempt to move .org backwards" issue.
---
arch/powerpc/kernel/epapr_paravirt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/epapr_paravirt.c b/arch/powerpc/kernel/epapr_paravirt.c
index eab2f2a..c47fed0 100644
--- a/arch/powerpc/kernel/epapr_paravirt.c
+++ b/arch/powerpc/kernel/epapr_paravirt.c
@@ -30,7 +30,7 @@ extern u32 epapr_ev_idle_start[];
#endif
bool epapr_paravirt_enabled;
-static bool epapr_has_idle;
+static bool __maybe_unused epapr_has_idle;
static int __init early_init_dt_scan_epapr(unsigned long node,
const char *uname,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH V4 0/2] mm: FAULT_AROUND_ORDER patchset performance data for powerpc
From: Hugh Dickins @ 2014-05-15 17:28 UTC (permalink / raw)
To: Madhavan Srinivasan
Cc: linux-arch, riel, rusty, dave.hansen, peterz, x86, linux-kernel,
linux-mm, ak, paulus, mgorman, akpm, linuxppc-dev, mingo,
kirill.shutemov
In-Reply-To: <537479E7.90806@linux.vnet.ibm.com>
On Thu, 15 May 2014, Madhavan Srinivasan wrote:
>
> 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.
Sorry for not commenting earlier - just reminded by this ping to Ingo.
I didn't study your numbers, but nowhere did I see what PAGE_SIZE you use.
arch/powerpc/Kconfig suggests that Power supports base page size of
4k, 16k, 64k or 256k.
I would expect your optimal fault_around_order to depend very much on
the base page size.
Perhaps fault_around_size would provide a more useful default?
Hugh
^ permalink raw reply
* Re: roundup_pow_of_two() may not handle 64-bit integers
From: Brian Norris @ 2014-05-15 19:44 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, linuxppc-dev, Paul Mackerras, Linux Kernel
In-Reply-To: <29314.1400166189@warthog.procyon.org.uk>
On Thu, May 15, 2014 at 04:03:09PM +0100, David Howells wrote:
> 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...
That's another confusing point; the commit description says 'unsigned
long', but the code shows nothing of that sort, and the comments say
nearly the reverse (mentioning '32-bit and 64-bit', not 'unsigned
long'). The code only referenes ULL constants, and it selects a 32-bit
or 64-bit runtime version based on the type. To me, this demonstrates an
explicit design for "32-bit or 64-bit", regardless of the dimensions of
your 'long'.
So this leaves me with 2 main issues:
(1) Can we make <linux/ilog2.h> have some sense of consistency? If so,
how?
- Enforce the 'unsigned long' design (i.e., don't support
ilog2(u64) when sizeof(unsigned long) == 4)?
- Make all high-level macros automatically support 32-bit or 64-bit,
regardless of type?
- Split out 32-bit vs. 64-bit functions for everything?
Obviously some of these options are sillier than others.
(2) Powerpc (and maybe some of SH's PCI) code has a potential bug, due
to using roundup_pow_of_two() on type phys_addr_t, which could
overflow for LPAE systems with large physical memory ranges. Is this
a legitimate concern?
Brian
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
From: Michael Neuling @ 2014-05-16 0:26 UTC (permalink / raw)
To: Pedro Alves
Cc: avagin, linux-kernel, oleg, michael, linuxppc-dev,
Anshuman Khandual
In-Reply-To: <5374AE24.1030302@redhat.com>
> 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.
Good point... agreed. We should ENODEV when we don't have TM hardware
(like POWER7).
Mikey
^ permalink raw reply
* G5 Quad working with Linux PPC and RadeonHD
From: Luigi Burdo @ 2014-05-16 10:31 UTC (permalink / raw)
To: linuxppc-dev
Hi all i start one week ago to write massage in ubuntu about
my object i have Radeon Hd working on my Quad G5 thanks to linuxPPC .
But there are some things to fix
One RadeonHD mesa colors are wrong .
On RadeonHD 4650 ddr3 512mb i have full video acceleration and hdmi
audio working
On RadeonHD 6570 ddr3 2048mb i have video but no chars on windows and
icons .
this is my thread on ubuntu forum Apple User in lubuntu
there are all my experieces and the bugs found ...
too much things to write on a single email
http://ubuntuforums.org/showthread.php?t=2221421&page=6
Thanks for all !
Luigi
^ permalink raw reply
* question about hvc_opal.c
From: Himangi Saraogi @ 2014-05-16 18:04 UTC (permalink / raw)
To: jslaby, Greg KH, linuxppc-dev, linux-kernel; +Cc: Julia Lawall
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
Hi,
In function hvc_opal_probe I find :
hp = hvc_alloc(termno, 0, ops, MAX_VIO_PUT_CHARS);
if (IS_ERR(hp))
return PTR_ERR(hp);
Earlier, hpc_opal_privs[termno] is assigned pv which is allocated using
kzalloc. Shouldn't there be a kfree(pv) and the array element (which is
global) be made NULL before the return. Also, if array element is set to
NULL on the failure, then some cleanup must be done to undo the effect of
hvc_instantiate as well. Please let me know if the change is desirable.
Thanks.
Himangi
[-- Attachment #2: Type: text/html, Size: 699 bytes --]
^ permalink raw reply
* Re: question about hvc_opal.c
From: Greg KH @ 2014-05-16 18:26 UTC (permalink / raw)
To: Himangi Saraogi; +Cc: linuxppc-dev, jslaby, linux-kernel, Julia Lawall
In-Reply-To: <CAB78YHynbQ=cR-jDTHpwwVGgDO24fjXETO1Zp88QD=Vkjf+6GQ@mail.gmail.com>
On Fri, May 16, 2014 at 11:34:13PM +0530, Himangi Saraogi wrote:
> Hi,
>
> In function hvc_opal_probe I find :
>
> hp = hvc_alloc(termno, 0, ops, MAX_VIO_PUT_CHARS);
> if (IS_ERR(hp))
> return PTR_ERR(hp);
>
> Earlier, hpc_opal_privs[termno] is assigned pv which is allocated using
> kzalloc. Shouldn't there be a kfree(pv) and the array element (which is global)
> be made NULL before the return. Also, if array element is set to NULL on the
> failure, then some cleanup must be done to undo the effect of hvc_instantiate
> as well. Please let me know if the change is desirable.
Sounds reasonable, please send a patch.
^ permalink raw reply
* Re: [RFC PATCH 1/3] slub: search partial list on numa_mem_id(), instead of numa_node_id()
From: Nishanth Aravamudan @ 2014-05-16 23:37 UTC (permalink / raw)
To: Joonsoo Kim
Cc: Han Pingtian, mpm, penberg, linux-mm, paulus, Anton Blanchard,
David Rientjes, Christoph Lameter, linuxppc-dev, Wanpeng Li
In-Reply-To: <1391674026-20092-1-git-send-email-iamjoonsoo.kim@lge.com>
On 06.02.2014 [17:07:04 +0900], Joonsoo Kim wrote:
> Currently, if allocation constraint to node is NUMA_NO_NODE, we search
> a partial slab on numa_node_id() node. This doesn't work properly on the
> system having memoryless node, since it can have no memory on that node and
> there must be no partial slab on that node.
>
> On that node, page allocation always fallback to numa_mem_id() first. So
> searching a partial slab on numa_node_id() in that case is proper solution
> for memoryless node case.
>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Joonsoo, would you send this one on to Andrew?
Thanks,
Nish
^ permalink raw reply
* [PATCH] powerpc: numa: enable USE_PERCPU_NUMA_NODE_ID
From: Nishanth Aravamudan @ 2014-05-16 23:39 UTC (permalink / raw)
To: Andrew Morton
Cc: Lee Schermerhorn, Christoph Lameter, Mel Gorman, linux-mm,
Anton Blanchard, David Rientjes, Joonsoo Kim, linuxppc-dev
Based off 3bccd996 for ia64, convert powerpc to use the generic per-CPU
topology tracking, specifically:
initialize per cpu numa_node entry in start_secondary
remove the powerpc cpu_to_node()
define CONFIG_USE_PERCPU_NUMA_NODE_ID if NUMA
Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e099899..9125964 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -453,6 +453,10 @@ config NODES_SHIFT
default "4"
depends on NEED_MULTIPLE_NODES
+config USE_PERCPU_NUMA_NODE_ID
+ def_bool y
+ depends on NUMA
+
config ARCH_SELECT_MEMORY_MODEL
def_bool y
depends on PPC64
diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index c920215..5ecf7ea 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -20,19 +20,6 @@ struct device_node;
#include <asm/mmzone.h>
-static inline int cpu_to_node(int cpu)
-{
- int nid;
-
- nid = numa_cpu_lookup_table[cpu];
-
- /*
- * During early boot, the numa-cpu lookup table might not have been
- * setup for all CPUs yet. In such cases, default to node 0.
- */
- return (nid < 0) ? 0 : nid;
-}
-
#define parent_node(node) (node)
#define cpumask_of_node(node) ((node) == -1 ? \
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index e2a4232..b95be24 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -750,6 +750,11 @@ void start_secondary(void *unused)
}
traverse_core_siblings(cpu, true);
+ /*
+ * numa_node_id() works after this.
+ */
+ set_numa_node(numa_cpu_lookup_table[cpu]);
+
smp_wmb();
notify_cpu_starting(cpu);
set_cpu_online(cpu, true);
^ permalink raw reply related
* [PATCH 2/2] powerpc: numa: enable CONFIG_HAVE_MEMORYLESS_NODES
From: Nishanth Aravamudan @ 2014-05-16 23:41 UTC (permalink / raw)
To: Andrew Morton
Cc: Lee Schermerhorn, Christoph Lameter, Mel Gorman, linux-mm,
Anton Blanchard, David Rientjes, Joonsoo Kim, linuxppc-dev
In-Reply-To: <20140516233945.GI8941@linux.vnet.ibm.com>
Based off fd1197f1 for ia64, enable CONFIG_HAVE_MEMORYLESS_NODES if
NUMA. Initialize the local memory node in start_secondary.
With this commit and the preceding to enable
CONFIG_USER_PERCPU_NUMA_NODE_ID, which is a prerequisite, in a PowerKVM
guest with the following topology:
numactl --hardware
available: 3 nodes (0-2)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70
71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94
95 96 97 98 99
node 0 size: 1998 MB
node 0 free: 521 MB
node 1 cpus: 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114
115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132
133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150
151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168
169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186
187 188 189 190 191 192 193 194 195 196 197 198 199
node 1 size: 0 MB
node 1 free: 0 MB
node 2 cpus:
node 2 size: 2039 MB
node 2 free: 1739 MB
node distances:
node 0 1 2
0: 10 40 40
1: 40 10 40
2: 40 40 10
the unreclaimable slab is reduced by close to 130M:
Before:
Slab: 418176 kB
SReclaimable: 26624 kB
SUnreclaim: 391552 kB
After:
Slab: 298944 kB
SReclaimable: 31744 kB
SUnreclaim: 267200 kB
Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9125964..bd6dd6e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -457,6 +457,10 @@ config USE_PERCPU_NUMA_NODE_ID
def_bool y
depends on NUMA
+config HAVE_MEMORYLESS_NODES
+ def_bool y
+ depends on NUMA
+
config ARCH_SELECT_MEMORY_MODEL
def_bool y
depends on PPC64
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index b95be24..ebd7b9d 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -754,6 +754,7 @@ void start_secondary(void *unused)
* numa_node_id() works after this.
*/
set_numa_node(numa_cpu_lookup_table[cpu]);
+ set_numa_mem(local_memory_node(numa_cpu_lookup_table[cpu]));
smp_wmb();
notify_cpu_starting(cpu);
^ permalink raw reply related
* Re: G5 Quad working with Linux PPC and RadeonHD
From: Michel Dänzer @ 2014-05-17 3:53 UTC (permalink / raw)
To: Luigi Burdo; +Cc: linuxppc-dev
In-Reply-To: <BLU436-SMTP80159B93A5EE9CE9979A56C8310@phx.gbl>
On 16.05.2014 19:31, Luigi Burdo wrote:
> Hi all i start one week ago to write massage in ubuntu about
> my object i have Radeon Hd working on my Quad G5 thanks to linuxPPC .
>
> But there are some things to fix
> One RadeonHD mesa colors are wrong .
See https://bugs.freedesktop.org/show_bug.cgi?id=72877 . No progress yet
unfortunately.
> On RadeonHD 4650 ddr3 512mb i have full video acceleration and hdmi
> audio working
> On RadeonHD 6570 ddr3 2048mb i have video but no chars on windows and
> icons .
The latter sounds like
https://bugs.freedesktop.org/show_bug.cgi?id=74939 , which is fixed in
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=8da17f30c70f4494ce22ad781a1cee17041812f3
.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
^ permalink raw reply
* Re: G5 Quad working with Linux PPC and RadeonHD
From: Luigi Burdo @ 2014-05-17 8:28 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <5376DD44.4040402@daenzer.net>
Hi Michel D=C3=A4nzer thanks for your explanation about .
About the first post
https://bugs.freedesktop.org/show_bug.cgi?id=3D72877
Christian (Xeno74) had been success to have the right mesa/gl colors on
X1000 machine he make a patch about =2C i tested his package on QuadG5
but no effect probably something is different in kernel/hardware (?!?)
about the second
on X1000 r600 boards dont gave decoration problems
there is probably needed some other trick about
for the other architecture.
https://bugs.freedesktop.org/show_bug.cgi?id=3D74939
In any way thanks alot for the infos and for the works
the PPC linux staff is doing :)
Luigi
Il 17/05/14 05:53=2C Michel D=C3=A4nzer ha scritto:
> On 16.05.2014 19:31=2C Luigi Burdo wrote:
>> Hi all i start one week ago to write massage in ubuntu about
>> my object i have Radeon Hd working on my Quad G5 thanks to linuxPPC .
>>
>> But there are some things to fix
>> One RadeonHD mesa colors are wrong .
> See https://bugs.freedesktop.org/show_bug.cgi?id=3D72877 . No progress ye=
t
> unfortunately.
>
>
>> On RadeonHD 4650 ddr3 512mb i have full video acceleration and hdmi
>> audio working
>> On RadeonHD 6570 ddr3 2048mb i have video but no chars on windows and
>> icons .
> The latter sounds like
> https://bugs.freedesktop.org/show_bug.cgi?id=3D74939 =2C which is fixed i=
n
> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=3D8da17=
f30c70f4494ce22ad781a1cee17041812f3
> .
>
>
^ 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