* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Rex Feany @ 2009-09-29 21:03 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <OF94793A12.243E8E02-ONC1257640.0040DE05-C1257640.00419DBD@transmode.se>
Thus spake Joakim Tjernlund (joakim.tjernlund@transmode.se):
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 29/09/2009 10:16:38:
> >
> >
> > > hmm, yes. You do get this and mysterious SEGV if you hit the but so does
> > > other bugs too so this is probably due to missing invalidation.
> > >
> > > I suspect that something like below will fix the problem and
> > > is the "correct" fix(untested, not even compiled):
> >
> > Ok but do we also still have to worry about the "unpopulated" TLB
> > entries and invalidate them somehow when populating ?
>
> Since I am probably the only one that knows about DAR problem I figured
> I should take a stab at it. This is not tested, but I hope Rex and the list
> can do that. Once this works as it should, we can remove all special handling
> for 8xx in copy_tofrom_user() and friends.
> No sign-off yet, want some confirmation first.
It doesn't make a difference. I applied it to the top of the tree,
it got to userspace but it is stuck. Using break I am able to dump the
registers, I'm not sure if this is useful. Oh, well, I finally got to a shell
but it is unusably slow. Is there some test code that would be better to run?
I tried looking through the mailing list archives but I couldn't find anything.
thanks!
/rex.
SysRq : Show Regs
NIP: c00588d0 LR: c000e3c4 CTR: 00001fde
REGS: c3459d90 TRAP: 0501 Not tainted (2.6.32-rc2-00013-g2d222d9-dirty)
MSR: 00009032 <EE,ME,IR,DR> CR: 44008422 XER: 20006a02
TASK = c3438050[13] 'rc.sysinit' THREAD: c3458000
GPR00: c000e3c4 c3459e40 c3438050 c21a2a60 c345bdf4 0fd81032 00000000 3001e920
GPR08: 00000000 00000005 c21a2a60 c0210000 03438260
NIP [c00588d0] handle_mm_fault+0x10/0xacc
LR [c000e3c4] do_page_fault+0x2f0/0x474
Call Trace:
[c3459e40] [c0059328] handle_mm_fault+0xa68/0xacc (unreliable)
[c3459e90] [c000e418] do_page_fault+0x344/0x474
[c3459f40] [c000d520] handle_page_fault+0xc/0x80
Instruction dump:
4bff15f1 39600000 80010014 7d635b78 7c0803a6 bbc10008 38210010 4e800020
7c0802a6 9421ffb0 3d60c021 be810020 <90010054> 38000000 90020000 396b4bec
SysRq : Show Regs
NIP: c000e0e0 LR: c000d520 CTR: 00001fde
REGS: c21adde0 TRAP: 0501 Not tainted (2.6.32-rc2-00013-g2d222d9-dirty)
MSR: 00009032 <EE,ME,IR,DR> CR: 48008424 XER: 00006a02
TASK = c3438460[18] 'sh' THREAD: c21ac000
GPR00: c000d520 c21ade90 c3438460 c21adf50 0fd76cb8 c0000000 00000004 0fee8c44
GPR08: 00009f6c c000d788 00009032 c000d514 03438670
NIP [c000e0e0] do_page_fault+0xc/0x474
LR [c000d520] handle_page_fault+0xc/0x80
Call Trace:
[c21ade90] [c000e418] do_page_fault+0x344/0x474 (unreliable)
[c21adf40] [c000d520] handle_page_fault+0xc/0x80
Instruction dump:
3863f604 7fe4fb78 7fc5f378 4bffcd39 80010014 bbc10008 7c0803a6 38210010
4e800020 7c0802a6 9421ff50 bf010090 <900100b4> 7c7e1b78 800300a0 7c9d2378
SysRq : Show Regs
NIP: c005930c LR: c000e3c4 CTR: 00001fde
REGS: c21add90 TRAP: 0501 Not tainted (2.6.32-rc2-00013-g2d222d9-dirty)
MSR: 00009032 <EE,ME,IR,DR> CR: 24002422 XER: 00006a02
TASK = c3438460[18] 'sh' THREAD: c21ac000
GPR00: c0236000 c21ade40 c3438460 c21a2a60 c3444df4 c3456000 00000000 feff0000
GPR08: c21ac000 03456000 c0220000 00000001 03438670
NIP [c005930c] handle_mm_fault+0xa4c/0xacc
LR [c000e3c4] do_page_fault+0x2f0/0x474
Call Trace:
[c21ade40] [c0059328] handle_mm_fault+0xa68/0xacc (unreliable)
[c21ade90] [c000e3c4] do_page_fault+0x2f0/0x474
[c21adf40] [c000d520] handle_page_fault+0xc/0x80
Instruction dump:
4802192d 48000094 2f9f0000 3ba00001 419e0088 7fe3fb78 4bff46a1 48000078
7fe3fb78 4bff4695 48000070 63390020 <633f0080> 7f45d378 7f63db78 7f04c378
^ permalink raw reply
* [PATCH] powerpc/5200: add LocalPlus bus FIFO device driver
From: John Bonesio @ 2009-09-29 20:43 UTC (permalink / raw)
To: linuxppc-dev
This is a driver for the FIFO device on the LocalPlus bus on an mpc5200 system.
The driver supports programmed I/O through the FIFO as well as setting up DMA
via the BestComm engine through the FIFO.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: John Bonesio <bones@secretlab.ca>
---
This driver was originally written by Grant Likely. I have updated it so that
transmitting data (as opposed to receiving data) works better. The driver has
been tested for all 6 transfer modes:
PIO mode (rx and tx)
DMA polled mode (rx and tx)
DMA interrupt mode (rx and tx)
- John
arch/powerpc/include/asm/mpc52xx.h | 39 ++
arch/powerpc/platforms/52xx/Kconfig | 5
arch/powerpc/platforms/52xx/Makefile | 1
arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 560 +++++++++++++++++++++++++
4 files changed, 605 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
diff --git a/arch/powerpc/include/asm/mpc52xx.h b/arch/powerpc/include/asm/mpc52xx.h
index 8273357..819a0be 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -282,6 +282,45 @@ extern int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, int period,
int continuous);
extern void mpc52xx_gpt_stop_timer(struct mpc52xx_gpt_priv *gpt);
+/* mpc52xx_lpbfifo.c */
+#define MPC52XX_LPBFIFO_FLAG_READ (0)
+#define MPC52XX_LPBFIFO_FLAG_WRITE (1<<0)
+#define MPC52XX_LPBFIFO_FLAG_NO_INCREMENT (1<<1)
+#define MPC52XX_LPBFIFO_FLAG_NO_DMA (1<<2)
+#define MPC52XX_LPBFIFO_FLAG_POLL_DMA (1<<3)
+
+struct mpc52xx_lpbfifo_request {
+ struct list_head list;
+
+ /* localplus bus address */
+ unsigned int cs;
+ size_t offset;
+
+ /* Memory address */
+ void *data;
+ phys_addr_t data_phys;
+
+ /* Details of transfer */
+ size_t size;
+ size_t pos; /* current position of transfer */
+ int flags;
+
+ /* What to do when finished */
+ void (*callback)(struct mpc52xx_lpbfifo_request *);
+
+ void *priv; /* Driver private data */
+
+ /* statistics */
+ int irq_count;
+ int irq_ticks;
+ u8 last_byte;
+ int buffer_not_done_cnt;
+};
+
+extern int mpc52xx_lpbfifo_submit(struct mpc52xx_lpbfifo_request *req);
+extern void mpc52xx_lpbfifo_abort(struct mpc52xx_lpbfifo_request *req);
+extern void mpc52xx_lpbfifo_poll(void);
+
/* mpc52xx_pic.c */
extern void mpc52xx_init_irq(void);
extern unsigned int mpc52xx_get_irq(void);
diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
index 696a5ee..ea00b3d 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -51,3 +51,8 @@ config PPC_MPC5200_GPIO
select GENERIC_GPIO
help
Enable gpiolib support for mpc5200 based boards
+
+config PPC_MPC5200_LPBFIFO
+ tristate "MPC5200 LocalPlus bus FIFO driver"
+ depends on PPC_MPC52xx
+ select PPC_BESTCOMM_GEN_BD
diff --git a/arch/powerpc/platforms/52xx/Makefile b/arch/powerpc/platforms/52xx/Makefile
index d6ade3d..8df23af 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -14,3 +14,4 @@ ifeq ($(CONFIG_PPC_LITE5200),y)
endif
obj-$(CONFIG_PPC_MPC5200_GPIO) += mpc52xx_gpio.o
+obj-$(CONFIG_PPC_MPC5200_LPBFIFO) += mpc52xx_lpbfifo.o
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
new file mode 100644
index 0000000..929d017
--- /dev/null
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -0,0 +1,560 @@
+/*
+ * LocalPlus Bus FIFO driver for the Freescale MPC52xx.
+ *
+ * Copyright (C) 2009 Secret Lab Technologies Ltd.
+ *
+ * This file is released under the GPLv2
+ *
+ * Todo:
+ * - Add support for multiple requests to be queued.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/spinlock.h>
+#include <asm/io.h>
+#include <asm/prom.h>
+#include <asm/mpc52xx.h>
+#include <asm/time.h>
+
+#include <sysdev/bestcomm/bestcomm.h>
+#include <sysdev/bestcomm/bestcomm_priv.h>
+#include <sysdev/bestcomm/gen_bd.h>
+
+MODULE_AUTHOR("Grant Likely <grant.likely@secretlab.ca>");
+MODULE_DESCRIPTION("MPC5200 LocalPlus FIFO device driver");
+MODULE_LICENSE("GPL");
+
+#define LPBFIFO_REG_PACKET_SIZE (0x00)
+#define LPBFIFO_REG_START_ADDRESS (0x04)
+#define LPBFIFO_REG_CONTROL (0x08)
+#define LPBFIFO_REG_ENABLE (0x0C)
+#define LPBFIFO_REG_BYTES_DONE_STATUS (0x14)
+#define LPBFIFO_REG_FIFO_DATA (0x40)
+#define LPBFIFO_REG_FIFO_STATUS (0x44)
+#define LPBFIFO_REG_FIFO_CONTROL (0x48)
+#define LPBFIFO_REG_FIFO_ALARM (0x4C)
+
+struct mpc52xx_lpbfifo {
+ struct device *dev;
+ phys_addr_t regs_phys;
+ void __iomem *regs;
+ int irq;
+ spinlock_t lock;
+
+ struct bcom_task *bcom_tx_task;
+ struct bcom_task *bcom_rx_task;
+ struct bcom_task *bcom_cur_task;
+
+ /* Current state data */
+ struct mpc52xx_lpbfifo_request *req;
+ int dma_irqs_enabled;
+};
+
+/* The MPC5200 has only one fifo, so only need one instance structure */
+static struct mpc52xx_lpbfifo lpbfifo;
+
+/**
+ * mpc52xx_lpbfifo_kick - Trigger the next block of data to be transfered
+ */
+static void mpc52xx_lpbfifo_kick(struct mpc52xx_lpbfifo_request *req)
+{
+ size_t transfer_size = req->size - req->pos;
+ struct bcom_bd *bd;
+ void __iomem *reg;
+ u32 *data;
+ int i;
+ int bit_fields;
+ int dma = !(req->flags & MPC52XX_LPBFIFO_FLAG_NO_DMA);
+ int write = req->flags & MPC52XX_LPBFIFO_FLAG_WRITE;
+ int poll_dma = req->flags & MPC52XX_LPBFIFO_FLAG_POLL_DMA;
+
+ /* Set and clear the reset bits; is good practice in User Manual */
+ out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, 0x01010000);
+
+ /* set master enable bit */
+ out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, 0x00000001);
+ if (!dma) {
+ /* While the FIFO can be setup for transfer sizes as large as
+ * 16M-1, the FIFO itself is only 512 bytes deep and it does
+ * not generate interrupts for FIFO full events (only transfer
+ * complete will raise an IRQ). Therefore when not using
+ * Bestcomm to drive the FIFO it needs to either be polled, or
+ * transfers need to constrained to the size of the fifo.
+ *
+ * This driver restricts the size of the transfer
+ */
+ if (transfer_size > 512)
+ transfer_size = 512;
+
+ /* Load the FIFO with data */
+ if (write) {
+ reg = lpbfifo.regs + LPBFIFO_REG_FIFO_DATA;
+ data = req->data + req->pos;
+ for (i = 0; i < transfer_size; i += 4)
+ out_be32(reg, *data++);
+ }
+
+ /* Unmask both error and completion irqs */
+ out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, 0x00000301);
+ } else {
+ /* Choose the correct direction
+ *
+ * Configure the watermarks so DMA will always complete correctly.
+ * It may be worth experimenting with the ALARM value to see if
+ * there is a performance impacit. However, if it is wrong there
+ * is a risk of DMA not transferring the last chunk of data
+ */
+ if (write) {
+ out_be32(lpbfifo.regs + LPBFIFO_REG_FIFO_ALARM, 0x1e4);
+ out_8(lpbfifo.regs + LPBFIFO_REG_FIFO_CONTROL, 7);
+ lpbfifo.bcom_cur_task = lpbfifo.bcom_tx_task;
+ } else {
+ out_be32(lpbfifo.regs + LPBFIFO_REG_FIFO_ALARM, 0x1ff);
+ out_8(lpbfifo.regs + LPBFIFO_REG_FIFO_CONTROL, 0);
+ lpbfifo.bcom_cur_task = lpbfifo.bcom_rx_task;
+
+ if (poll_dma) {
+ if (lpbfifo.dma_irqs_enabled) {
+ disable_irq(bcom_get_task_irq(lpbfifo.bcom_rx_task));
+ lpbfifo.dma_irqs_enabled = 0;
+ }
+ } else {
+ if (!lpbfifo.dma_irqs_enabled) {
+ enable_irq(bcom_get_task_irq(lpbfifo.bcom_rx_task));
+ lpbfifo.dma_irqs_enabled = 1;
+ }
+ }
+ }
+
+ bd = bcom_prepare_next_buffer(lpbfifo.bcom_cur_task);
+ bd->status = transfer_size;
+ if (!write) {
+ /*
+ * In the DMA read case, the DMA doesn't complete,
+ * possibly due to incorrect watermarks in the ALARM
+ * and CONTROL regs. For now instead of trying to
+ * determine the right watermarks that will make this
+ * work, just increase the number of bytes the FIFO is
+ * expecting.
+ *
+ * When submitting another operation, the FIFO will get
+ * reset, so the condition of the FIFO waiting for a
+ * non-existent 4 bytes will get cleared.
+ */
+ transfer_size += 4; /* BLECH! */
+ }
+ bd->data[0] = req->data_phys + req->pos;
+ bcom_submit_next_buffer(lpbfifo.bcom_cur_task, NULL);
+
+ /* error irq & master enabled bit */
+ bit_fields = 0x00000201;
+
+ /* Unmask irqs */
+ if (write && (!poll_dma))
+ bit_fields |= 0x00000100; /* completion irq too */
+ out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, bit_fields);
+ }
+
+ /* Set transfer size, width, chip select and READ mode */
+ out_be32(lpbfifo.regs + LPBFIFO_REG_START_ADDRESS,
+ req->offset + req->pos);
+ out_be32(lpbfifo.regs + LPBFIFO_REG_PACKET_SIZE, transfer_size);
+
+ bit_fields = req->cs << 24 | 0x000008;
+ if (!write)
+ bit_fields |= 0x010000; /* read mode */
+ out_be32(lpbfifo.regs + LPBFIFO_REG_CONTROL, bit_fields);
+
+ /* Kick it off */
+ out_8(lpbfifo.regs + LPBFIFO_REG_PACKET_SIZE, 0x01);
+ if (dma)
+ bcom_enable(lpbfifo.bcom_cur_task);
+}
+
+/**
+ * mpc52xx_lpbfifo_irq - IRQ handler for LPB FIFO
+ *
+ * On transmit, the dma completion irq triggers before the fifo completion
+ * triggers. Handle the dma completion here instead of the LPB FIFO Bestcomm
+ * task completion irq becuase everyting is not really done until the LPB FIFO
+ * completion irq triggers.
+ *
+ * In other words:
+ * For DMA, on receive, the "Fat Lady" is the bestcom completion irq. on
+ * transmit, the fifo completion irq is the "Fat Lady". The opera (or in this
+ * case the DMA/FIFO operation) is not finished until the "Fat Lady" sings.
+ *
+ * Reasons for entering this routine:
+ * 1) PIO mode rx and tx completion irq
+ * 2) DMA interrupt mode tx completion irq
+ * 3) DMA polled mode tx
+ *
+ * Exit conditions:
+ * 1) Transfer aborted
+ * 2) FIFO complete without DMA; more data to do
+ * 3) FIFO complete without DMA; all data transfered
+ * 4) FIFO complete using DMA
+ *
+ * Condition 1 can occur regardless of whether or not DMA is used.
+ * It requires executing the callback to report the error and exiting
+ * immediately.
+ *
+ * Condition 2 requires programming the FIFO with the next block of data
+ *
+ * Condition 3 requires executing the callback to report completion
+ *
+ * Condition 4 means the same as 3, except that we also retrieve the bcom
+ * buffer so DMA doesn't get clogged up.
+ *
+ * To make things trickier, the spinlock must be dropped before
+ * executing the callback, otherwise we could end up with a deadlock
+ * or nested spinlock condition. The out path is non-trivial, so
+ * extra fiddling is done to make sure all paths lead to the same
+ * outbound code.
+ */
+static irqreturn_t mpc52xx_lpbfifo_irq(int irq, void *dev_id)
+{
+ struct mpc52xx_lpbfifo_request *req;
+ u32 status = in_8(lpbfifo.regs + LPBFIFO_REG_BYTES_DONE_STATUS);
+ void __iomem *reg;
+ u32 *data;
+ int count, i;
+ int do_callback = 0;
+ u32 ts;
+ unsigned long flags;
+ int dma, write, poll_dma;
+
+ spin_lock_irqsave(&lpbfifo.lock, flags);
+ ts = get_tbl();
+
+ req = lpbfifo.req;
+ if (!req) {
+ spin_unlock_irqrestore(&lpbfifo.lock, flags);
+ pr_err("bogus LPBFIFO IRQ\n");
+ return IRQ_HANDLED;
+ }
+
+ dma = !(req->flags & MPC52XX_LPBFIFO_FLAG_NO_DMA);
+ write = req->flags & MPC52XX_LPBFIFO_FLAG_WRITE;
+ poll_dma = req->flags & MPC52XX_LPBFIFO_FLAG_POLL_DMA;
+
+ if (dma && !write) {
+ spin_unlock_irqrestore(&lpbfifo.lock, flags);
+ pr_err("bogus LPBFIFO IRQ (dma and not writting)\n");
+ return IRQ_HANDLED;
+ }
+
+ if ((status & 0x01) == 0) {
+ goto out;
+ }
+
+ /* check abort bit */
+ if (status & 0x10) {
+ out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, 0x01010000);
+ do_callback = 1;
+ goto out;
+ }
+
+ /* Read result from hardware */
+ count = in_be32(lpbfifo.regs + LPBFIFO_REG_BYTES_DONE_STATUS);
+ count &= 0x00ffffff;
+
+ if (!dma && !write) {
+ /* copy the data out of the FIFO */
+ reg = lpbfifo.regs + LPBFIFO_REG_FIFO_DATA;
+ data = req->data + req->pos;
+ for (i = 0; i < count; i += 4)
+ *data++ = in_be32(reg);
+ }
+
+ /* Update transfer position and count */
+ req->pos += count;
+
+ /* Decide what to do next */
+ if (req->size - req->pos)
+ mpc52xx_lpbfifo_kick(req); /* more work to do */
+ else
+ do_callback = 1;
+
+ out:
+ /* Clear the IRQ */
+ out_8(lpbfifo.regs + LPBFIFO_REG_BYTES_DONE_STATUS, 0x01);
+
+ if (dma && (status & 0x11)) {
+ /*
+ * Count the DMA as complete only when the FIFO completion
+ * status or abort bits are set.
+ *
+ * (status & 0x01) should always be the case except sometimes
+ * when using polled DMA.
+ *
+ * (status & 0x10) {transfer aborted}: This case needs more
+ * testing.
+ */
+ bcom_retrieve_buffer(lpbfifo.bcom_cur_task, &status, NULL);
+ }
+ req->last_byte = ((u8 *)req->data)[req->size - 1];
+
+ /* When the do_callback flag is set; it means the transfer is finished
+ * so set the FIFO as idle */
+ if (do_callback)
+ lpbfifo.req = NULL;
+
+ if (irq != 0) /* don't increment on polled case */
+ req->irq_count++;
+
+ req->irq_ticks += get_tbl() - ts;
+ spin_unlock_irqrestore(&lpbfifo.lock, flags);
+
+ /* Spinlock is released; it is now safe to call the callback */
+ if (do_callback && req->callback)
+ req->callback(req);
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * mpc52xx_lpbfifo_bcom_irq - IRQ handler for LPB FIFO Bestcomm task
+ *
+ * Only used when receiving data.
+ */
+static irqreturn_t mpc52xx_lpbfifo_bcom_irq(int irq, void *dev_id)
+{
+ struct mpc52xx_lpbfifo_request *req;
+ unsigned long flags;
+ u32 status;
+ u32 ts;
+
+ spin_lock_irqsave(&lpbfifo.lock, flags);
+ ts = get_tbl();
+
+ req = lpbfifo.req;
+ if (!req || (req->flags & MPC52XX_LPBFIFO_FLAG_NO_DMA)) {
+ spin_unlock_irqrestore(&lpbfifo.lock, flags);
+ return IRQ_HANDLED;
+ }
+
+ if (irq != 0) /* don't increment on polled case */
+ req->irq_count++;
+
+ if (!bcom_buffer_done(lpbfifo.bcom_cur_task)) {
+ spin_unlock_irqrestore(&lpbfifo.lock, flags);
+
+ req->buffer_not_done_cnt++;
+ if ((req->buffer_not_done_cnt % 1000) == 0)
+ pr_err("transfer stalled\n");
+
+ return IRQ_HANDLED;
+ }
+
+ bcom_retrieve_buffer(lpbfifo.bcom_cur_task, &status, NULL);
+
+ req->last_byte = ((u8 *)req->data)[req->size - 1];
+
+ req->pos = status & 0x00ffffff;
+
+ /* Mark the FIFO as idle */
+ lpbfifo.req = NULL;
+
+ /* Release the lock before calling out to the callback. */
+ req->irq_ticks += get_tbl() - ts;
+ spin_unlock_irqrestore(&lpbfifo.lock, flags);
+
+ if (req->callback)
+ req->callback(req);
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * mpc52xx_lpbfifo_bcom_poll - Poll for DMA completion
+ */
+void mpc52xx_lpbfifo_poll(void)
+{
+ struct mpc52xx_lpbfifo_request *req = lpbfifo.req;
+ int dma = !(req->flags & MPC52XX_LPBFIFO_FLAG_NO_DMA);
+ int write = req->flags & MPC52XX_LPBFIFO_FLAG_WRITE;
+
+ /*
+ * For more information, see comments on the "Fat Lady"
+ */
+ if (dma && write)
+ mpc52xx_lpbfifo_irq(0, NULL);
+ else
+ mpc52xx_lpbfifo_bcom_irq(0, NULL);
+}
+EXPORT_SYMBOL(mpc52xx_lpbfifo_poll);
+
+/**
+ * mpc52xx_lpbfifo_submit - Submit an LPB FIFO transfer request.
+ * @req: Pointer to request structure
+ */
+int mpc52xx_lpbfifo_submit(struct mpc52xx_lpbfifo_request *req)
+{
+ unsigned long flags;
+
+ if (!lpbfifo.regs)
+ return -ENODEV;
+
+ spin_lock_irqsave(&lpbfifo.lock, flags);
+
+ /* If the req pointer is already set, then a transfer is in progress */
+ if (lpbfifo.req) {
+ spin_unlock_irqrestore(&lpbfifo.lock, flags);
+ return -EBUSY;
+ }
+
+ /* Setup the transfer */
+ lpbfifo.req = req;
+ req->irq_count = 0;
+ req->irq_ticks = 0;
+ req->buffer_not_done_cnt = 0;
+ req->pos = 0;
+
+ mpc52xx_lpbfifo_kick(req);
+ spin_unlock_irqrestore(&lpbfifo.lock, flags);
+ return 0;
+}
+EXPORT_SYMBOL(mpc52xx_lpbfifo_submit);
+
+void mpc52xx_lpbfifo_abort(struct mpc52xx_lpbfifo_request *req)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&lpbfifo.lock, flags);
+ if (lpbfifo.req == req) {
+ /* Put it into reset and clear the state */
+ bcom_gen_bd_rx_reset(lpbfifo.bcom_rx_task);
+ bcom_gen_bd_tx_reset(lpbfifo.bcom_tx_task);
+ out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, 0x01010000);
+ lpbfifo.req = NULL;
+ }
+ spin_unlock_irqrestore(&lpbfifo.lock, flags);
+}
+EXPORT_SYMBOL(mpc52xx_lpbfifo_abort);
+
+static int __devinit
+mpc52xx_lpbfifo_probe(struct of_device *op, const struct of_device_id *match)
+{
+ struct resource res;
+ int rc = -ENOMEM;
+
+ if (lpbfifo.dev != NULL)
+ return -ENOSPC;
+
+ lpbfifo.irq = irq_of_parse_and_map(op->node, 0);
+ if (!lpbfifo.irq)
+ return -ENODEV;
+
+ if (of_address_to_resource(op->node, 0, &res))
+ return -ENODEV;
+ lpbfifo.regs_phys = res.start;
+ lpbfifo.regs = of_iomap(op->node, 0);
+ if (!lpbfifo.regs)
+ return -ENOMEM;
+
+ spin_lock_init(&lpbfifo.lock);
+
+ /* Put FIFO into reset */
+ out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, 0x01010000);
+
+ /* Register the interrupt handler */
+ rc = request_irq(lpbfifo.irq, mpc52xx_lpbfifo_irq, 0,
+ "mpc52xx-lpbfifo", &lpbfifo);
+ if (rc)
+ goto err_irq;
+
+ /* Request the Bestcomm receive (fifo --> memory) task and IRQ */
+ lpbfifo.bcom_rx_task =
+ bcom_gen_bd_rx_init(2, res.start + LPBFIFO_REG_FIFO_DATA,
+ BCOM_INITIATOR_SCLPC, BCOM_IPR_SCLPC,
+ 16*1024*1024);
+ if (!lpbfifo.bcom_rx_task)
+ goto err_bcom_rx;
+
+ rc = request_irq(bcom_get_task_irq(lpbfifo.bcom_rx_task),
+ mpc52xx_lpbfifo_bcom_irq, 0,
+ "mpc52xx-lpbfifo-rx", &lpbfifo);
+ if (rc)
+ goto err_bcom_rx_irq;
+
+ /* Request the Bestcomm transmit (memory --> fifo) task and IRQ */
+ lpbfifo.bcom_tx_task =
+ bcom_gen_bd_tx_init(2, res.start + LPBFIFO_REG_FIFO_DATA,
+ BCOM_INITIATOR_SCLPC, BCOM_IPR_SCLPC);
+ if (!lpbfifo.bcom_tx_task)
+ goto err_bcom_tx;
+
+ lpbfifo.dev = &op->dev;
+ return 0;
+
+ err_bcom_tx:
+ free_irq(bcom_get_task_irq(lpbfifo.bcom_rx_task), &lpbfifo);
+ err_bcom_rx_irq:
+ bcom_gen_bd_rx_release(lpbfifo.bcom_rx_task);
+ err_bcom_rx:
+ err_irq:
+ iounmap(lpbfifo.regs);
+ lpbfifo.regs = NULL;
+
+ dev_err(&op->dev, "mpc52xx_lpbfifo_probe() failed\n");
+ return -ENODEV;
+}
+
+
+static int __devexit mpc52xx_lpbfifo_remove(struct of_device *op)
+{
+ if (lpbfifo.dev != &op->dev)
+ return 0;
+
+ /* Put FIFO in reset */
+ out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, 0x01010000);
+
+ /* Release the bestcomm transmit task */
+ free_irq(bcom_get_task_irq(lpbfifo.bcom_tx_task), &lpbfifo);
+ bcom_gen_bd_tx_release(lpbfifo.bcom_tx_task);
+
+ /* Release the bestcomm receive task */
+ free_irq(bcom_get_task_irq(lpbfifo.bcom_rx_task), &lpbfifo);
+ bcom_gen_bd_rx_release(lpbfifo.bcom_rx_task);
+
+ free_irq(lpbfifo.irq, &lpbfifo);
+ iounmap(lpbfifo.regs);
+ lpbfifo.regs = NULL;
+ lpbfifo.dev = NULL;
+
+ return 0;
+}
+
+static struct of_device_id mpc52xx_lpbfifo_match[] __devinitconst = {
+ { .compatible = "fsl,mpc5200-lpbfifo", },
+ {},
+};
+
+static struct of_platform_driver mpc52xx_lpbfifo_driver = {
+ .owner = THIS_MODULE,
+ .name = "mpc52xx-lpbfifo",
+ .match_table = mpc52xx_lpbfifo_match,
+ .probe = mpc52xx_lpbfifo_probe,
+ .remove = __devexit_p(mpc52xx_lpbfifo_remove),
+};
+
+/***********************************************************************
+ * Module init/exit
+ */
+static int __init mpc52xx_lpbfifo_init(void)
+{
+ pr_debug("Registering LocalPlus bus FIFO driver\n");
+ return of_register_platform_driver(&mpc52xx_lpbfifo_driver);
+}
+module_init(mpc52xx_lpbfifo_init);
+
+static void __exit mpc52xx_lpbfifo_exit(void)
+{
+ pr_debug("Unregistering LocalPlus bus FIFO driver\n");
+ of_unregister_platform_driver(&mpc52xx_lpbfifo_driver);
+}
+module_exit(mpc52xx_lpbfifo_exit);
^ permalink raw reply related
* Re: [PATCH] powerpc: warning: allocated section `.data_nosave' not in segment
From: Segher Boessenkool @ 2009-09-29 20:40 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20090929120006.78affe3f@lappy.seanm.ca>
> We need to align before the output section. Having the align inside
> the output section causes the linker to put some filler in there,
> which makes it a non-empty section, but this section isn't assigned to
> a segment so you get a warning from the linker.
>
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
> ---
> diff --git a/arch/powerpc/kernel/vmlinux.lds.S
> b/arch/powerpc/kernel/vmlinux.lds.S index f564293..e853763 100644
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -236,6 +236,7 @@ SECTIONS
> READ_MOSTLY_DATA(L1_CACHE_BYTES)
> }
>
> + . = ALIGN(PAGE_SIZE);
> .data_nosave : AT(ADDR(.data_nosave) - LOAD_OFFSET) {
> NOSAVE_DATA
> }
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
The patch is good and fixes a real problem. But, I still don't see how
it caused the "warning: allocated section `.data_nosave' not in
segment",
it would be good if we can find out.
Segher
^ permalink raw reply
* [PATCH] powerpc: warning: allocated section `.data_nosave' not in segment
From: Sean MacLennan @ 2009-09-29 16:00 UTC (permalink / raw)
To: linuxppc-dev
We need to align before the output section. Having the align inside
the output section causes the linker to put some filler in there,
which makes it a non-empty section, but this section isn't assigned to
a segment so you get a warning from the linker.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S index f564293..e853763 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -236,6 +236,7 @@ SECTIONS
READ_MOSTLY_DATA(L1_CACHE_BYTES)
}
+ . = ALIGN(PAGE_SIZE);
.data_nosave : AT(ADDR(.data_nosave) - LOAD_OFFSET) {
NOSAVE_DATA
}
^ permalink raw reply
* RE: [PATCH v4] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570
From: John Linn @ 2009-09-29 15:14 UTC (permalink / raw)
To: Richard Röjfors
Cc: spi-devel-general, Andrew Morton, dbrownell, linuxppc-dev
In-Reply-To: <4AC1AA82.3040406@mocean-labs.com>
> -----Original Message-----
> From: Richard R=F6jfors [mailto:richard.rojfors@mocean-labs.com]
> Sent: Tuesday, September 29, 2009 12:35 AM
> To: John Linn
> Cc: spi-devel-general@lists.sourceforge.net; linuxppc-dev@ozlabs.org;
> dbrownell@users.sourceforge.net; Andrew Morton
> Subject: Re: [PATCH v4] xilinx_spi: Splitted into generic, of and platfor=
m driver, added support for
> DS570
> =
> On 9/28/09 5:41 PM, John Linn wrote:
> >> -----Original Message-----
> >> From: Richard R=F6jfors [mailto:richard.rojfors@mocean-labs.com]
> >> Sent: Monday, September 28, 2009 8:22 AM
> >> To: spi-devel-general@lists.sourceforge.net
> >> Cc: linuxppc-dev@ozlabs.org; dbrownell@users.sourceforge.net; Andrew M=
orton; John Linn
> >> Subject: [PATCH v4] xilinx_spi: Splitted into generic, of and platform=
driver, added support for
> >> DS570
> >>
> >> This patch splits xilinx_spi into three parts, an OF and a platform
> >> driver and generic part.
> >>
> >> The generic part now also works on X86, it supports accessing the IP
> >> booth big and little endian. There is also support for 16 and 32 bit
> >> SPI for the Xilinx SPI IP DS570
> >>
> >> Signed-off-by: Richard R=F6jfors <richard.rojfors@mocean-labs.com>
> >> ---
> >> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> >> index 2c733c2..ecabc12 100644
> >> --- a/drivers/spi/Kconfig
> >> +++ b/drivers/spi/Kconfig
> >> @@ -218,8 +218,8 @@ config SPI_TXX9
> >> SPI driver for Toshiba TXx9 MIPS SoCs
> >>
> >
> > <snip>
> >
> >>
> >> -struct xilinx_spi {
> >> - /* bitbang has to be first */
> >> - struct spi_bitbang bitbang;
> >> - struct completion done;
> >> +/* to follow are some functions that does little of big endian read a=
nd
> >> + * write depending on the config of the device.
> >> + */
> >> +static inline void xspi_write8(struct xilinx_spi *xspi, u32 offs, u8 =
val)
> >> +{
> >> + iowrite8(val, xspi->regs + offs + ((xspi->big_endian) ? 3 : 0));
> >> +}
> >>
> >> - void __iomem *regs; /* virt. address of the control registers */
> >> +static inline void xspi_write16(struct xilinx_spi *xspi, u32 offs, u1=
6 val)
> >> +{
> >> + if (xspi->big_endian)
> >> + iowrite16be(val, xspi->regs + offs + 2);
> >> + else
> >> + iowrite16(val, xspi->regs + offs);
> >> +}
> >
> >
> > Hi Richard,
> =
> Hi John,
> =
> Thanks for the quick feedback.
No problem. I thought at 1st that the point of the new code was performance=
, but it sounds like you're trying to make sure the driver will work with a=
system that can be built in many different permutations.
> =
> > If you're worried about efficiency (the reason for 16 and 32 bit xfers)=
, why wouldn't you do the
> big-endian vs little endian I/O decision at compile time rather than run =
time?
> =
> I'm afraid we can't do it compile time, if we want to be flexible. As
> example;
> The IP is big endian, in our case the PCI interface flips the byte
> order. But the PCI interface might be setup differently ->would be
> accessed big endian even on a little endian machine.
> =
Ok I see the flexibility requirements.
> We could use callbacks set up during probe, instead of having the
> if-sentence. But I don't think the callback solution could be slower (if
> talking performance), since the compiler can't inline them, the current
> functions could be inlined if the compiler feels like it.
> =
> =
> > The big_endian variable is not a constant boolean, I don't know if that=
could help so that the
> compiler optimizes this check away? Or maybe it is already and I'm just =
missing that?
> >
> >>
> >> - u32 irq;
> >> +static inline void xspi_write32(struct xilinx_spi *xspi, u32 offs, u3=
2 val)
> >> +{
> >> + if (xspi->big_endian)
> >> + iowrite32be(val, xspi->regs + offs);
> >> + else
> >> + iowrite32(val, xspi->regs + offs);
> >> +}
> >>
> >> - u32 speed_hz; /* SCK has a fixed frequency of speed_hz Hz */
> >> +static inline u8 xspi_read8(struct xilinx_spi *xspi, u32 offs)
> >> +{
> >> + return ioread8(xspi->regs + offs + ((xspi->big_endian) ? 3 : 0));
> >> +}
> >>
> >> - u8 *rx_ptr; /* pointer in the Tx buffer */
> >> - const u8 *tx_ptr; /* pointer in the Rx buffer */
> >> - int remaining_bytes; /* the number of bytes left to transfer */
> >> -};
> >
> > <snip>
> >
> >> -
> >> /* This driver supports single master mode only. Hence Tx FIFO Empty
> >> * is the only interrupt we care about.
> >> * Receive FIFO Overrun, Transmit FIFO Underrun, Mode Fault, and Slav=
e Mode
> >> @@ -237,32 +298,50 @@ static irqreturn_t xilinx_spi_irq(int irq, void =
*dev_id)
> >> u32 ipif_isr;
> >>
> >> /* Get the IPIF interrupts, and clear them immediately */
> >> - ipif_isr =3D in_be32(xspi->regs + XIPIF_V123B_IISR_OFFSET);
> >> - out_be32(xspi->regs + XIPIF_V123B_IISR_OFFSET, ipif_isr);
> >> + ipif_isr =3D xspi_read32(xspi, XIPIF_V123B_IISR_OFFSET);
> >> + xspi_write32(xspi, XIPIF_V123B_IISR_OFFSET, ipif_isr);
> >>
> >> if (ipif_isr & XSPI_INTR_TX_EMPTY) { /* Transmission completed */
> >> u16 cr;
> >> u8 sr;
> >> + u8 rsize;
> >> + if (xspi->bits_per_word =3D=3D 8)
> >> + rsize =3D 1;
> >> + else if (xspi->bits_per_word =3D=3D 16)
> >> + rsize =3D 2;
> >> + else
> >> + rsize =3D 4;
> >>
> >> /* A transmit has just completed. Process received data and
> >> * check for more data to transmit. Always inhibit the
> >> * transmitter while the Isr refills the transmit register/FIFO,
> >> * or make sure it is stopped if we're done.
> >> */
> >> - cr =3D in_be16(xspi->regs + XSPI_CR_OFFSET);
> >> - out_be16(xspi->regs + XSPI_CR_OFFSET,
> >> - cr | XSPI_CR_TRANS_INHIBIT);
> >> + cr =3D xspi_read16(xspi, XSPI_CR_OFFSET);
> >> + xspi_write16(xspi, XSPI_CR_OFFSET, cr | XSPI_CR_TRANS_INHIBIT);
> >>
> >> /* Read out all the data from the Rx FIFO */
> >> - sr =3D in_8(xspi->regs + XSPI_SR_OFFSET);
> >> + sr =3D xspi_read8(xspi, XSPI_SR_OFFSET);
> >> while ((sr & XSPI_SR_RX_EMPTY_MASK) =3D=3D 0) {
> >> - u8 data;
> >> + u32 data;
> >> + if (rsize =3D=3D 1)
> >> + data =3D xspi_read8(xspi, XSPI_RXD_OFFSET);
> >> + else if (rsize =3D=3D 2)
> >> + data =3D xspi_read16(xspi, XSPI_RXD_OFFSET);
> >> + else
> >> + data =3D xspi_read32(xspi, XSPI_RXD_OFFSET);
> >>
> >> - data =3D in_8(xspi->regs + XSPI_RXD_OFFSET);
> >> if (xspi->rx_ptr) {
> >> - *xspi->rx_ptr++ =3D data;
> >> + if (rsize =3D=3D 1)
> >> + *xspi->rx_ptr =3D data & 0xff;
> >> + else if (rsize =3D=3D 2)
> >> + *(u16 *)(xspi->rx_ptr) =3D data & 0xffff;
> >> + else
> >> + *((u32 *)(xspi->rx_ptr)) =3D data;
> >> + xspi->rx_ptr +=3D rsize;
> >
> > Maybe I'm out of line here...
> >
> > I'm wondering if this is going to be any more efficient that just using=
8 bit accesses
> =
> We can not do 8 bit accesses if the IP is set up to do 16/32bit SPI,
> then the TX/RX registers are as wide as the bit setup.
> =
> We could do 32 bit reads from the registers, then we waste some cycles
> on the PLB bus, but have slightly simpler code.
Looking at the IP spec, it looks like 32 bit operations to registers should=
work and that sounds like the right direction to go (32 bit only).
Doing 32 bit operations on the PLB, rather than 8 bit operations, won't was=
te any cycles on the bus as you're on the bus either way so it can't be use=
d by any other device, it's just how many byte lanes are being used on the =
bus.
> =
> > as it seems like the amount of run-time decisions being made is quite a=
few. I guess it depends on
> how many bytes are being transferred as with big transfers maybe it will =
pay off.
> >
> > In my opinion, which isn't worth much many times :), sometimes the flex=
ibility with soft logic,
> like this is a pain for testability and increases complexity. If there's =
reasonable performance gains
> then maybe it's a good tradeoff.
> >
> > Do you know how much performance gain there is or is expected as maybe =
you've seen the pay off
> already?
> =
> I haven't done any measurements, and we are basically only controlling
> GPIO so performance is not an issue for us. I just didn't want do make
> it slower. I think you have more experience here. Do you think it's
> better to just do 32bit reads to make the code simple? If so I will
> update the code.
Yes, 32 ops.
If you get a new driver that's ready, I can hopefully find some time to tes=
t it in our automated test with the SPI EEPROM.
> =
> Thanks
> --Richard
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [PATCH 1/1] powerpc: Add kdump support to Collaborative Memory Manager
From: Brian King @ 2009-09-29 14:46 UTC (permalink / raw)
To: benh; +Cc: brking, linuxppc-dev
When running Active Memory Sharing, the Collaborative Memory Manager (CMM)
may mark some pages as "loaned" with the hypervisor. Periodically, the
CMM will query the hypervisor for a loan request, which is a single signed
value. When kexec'ing into a kdump kernel, the CMM driver in the kdump
kernel is not aware of the pages the previous kernel had marked as "loaned",
so the hypervisor and the CMM driver are out of sync. Fix the CMM driver
to handle this scenario by ignoring requests to decrease the number of loaned
pages if we don't think we have any pages loaned. Pages that are marked as
"loaned" which are not in the balloon will automatically get switched to "active"
the next time we touch the page. This also fixes the case where totalram_pages
is smaller than min_mem_mb, which can occur during kdump.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/Kconfig | 2 +-
arch/powerpc/platforms/pseries/cmm.c | 29 +++++++++++++++++++----------
2 files changed, 20 insertions(+), 11 deletions(-)
diff -puN arch/powerpc/platforms/pseries/cmm.c~powerpc_cmm_fix_kdump arch/powerpc/platforms/pseries/cmm.c
--- linux-2.6/arch/powerpc/platforms/pseries/cmm.c~powerpc_cmm_fix_kdump 2009-09-24 16:35:00.000000000 -0500
+++ linux-2.6-bjking1/arch/powerpc/platforms/pseries/cmm.c 2009-09-25 10:24:19.000000000 -0500
@@ -229,8 +229,9 @@ static void cmm_get_mpp(void)
{
int rc;
struct hvcall_mpp_data mpp_data;
- unsigned long active_pages_target;
- signed long page_loan_request;
+ signed long active_pages_target, page_loan_request, target;
+ signed long total_pages = totalram_pages + loaned_pages;
+ signed long min_mem_pages = (min_mem_mb * 1024 * 1024) / PAGE_SIZE;
rc = h_get_mpp(&mpp_data);
@@ -238,17 +239,25 @@ static void cmm_get_mpp(void)
return;
page_loan_request = div_s64((s64)mpp_data.loan_request, PAGE_SIZE);
- loaned_pages_target = page_loan_request + loaned_pages;
- if (loaned_pages_target > oom_freed_pages)
- loaned_pages_target -= oom_freed_pages;
+ target = page_loan_request + (signed long)loaned_pages;
+
+ if (target < 0 || total_pages < min_mem_pages)
+ target = 0;
+
+ if (target > oom_freed_pages)
+ target -= oom_freed_pages;
else
- loaned_pages_target = 0;
+ target = 0;
+
+ active_pages_target = total_pages - target;
+
+ if (min_mem_pages > active_pages_target)
+ target = total_pages - min_mem_pages;
- active_pages_target = totalram_pages + loaned_pages - loaned_pages_target;
+ if (target < 0)
+ target = 0;
- if ((min_mem_mb * 1024 * 1024) > (active_pages_target * PAGE_SIZE))
- loaned_pages_target = totalram_pages + loaned_pages -
- ((min_mem_mb * 1024 * 1024) / PAGE_SIZE);
+ loaned_pages_target = target;
cmm_dbg("delta = %ld, loaned = %lu, target = %lu, oom = %lu, totalram = %lu\n",
page_loan_request, loaned_pages, loaned_pages_target,
diff -puN arch/powerpc/platforms/pseries/Kconfig~powerpc_cmm_fix_kdump arch/powerpc/platforms/pseries/Kconfig
--- linux-2.6/arch/powerpc/platforms/pseries/Kconfig~powerpc_cmm_fix_kdump 2009-09-24 16:35:00.000000000 -0500
+++ linux-2.6-bjking1/arch/powerpc/platforms/pseries/Kconfig 2009-09-24 16:35:00.000000000 -0500
@@ -59,7 +59,7 @@ config PPC_SMLPAR
config CMM
tristate "Collaborative memory management"
- depends on PPC_SMLPAR && !CRASH_DUMP
+ depends on PPC_SMLPAR
default y
help
Select this option, if you want to enable the kernel interface
_
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Joakim Tjernlund @ 2009-09-29 11:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1254212198.5256.0.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 29/09/2009 10:16:38:
>
>
> > hmm, yes. You do get this and mysterious SEGV if you hit the but so does
> > other bugs too so this is probably due to missing invalidation.
> >
> > I suspect that something like below will fix the problem and
> > is the "correct" fix(untested, not even compiled):
>
> Ok but do we also still have to worry about the "unpopulated" TLB
> entries and invalidate them somehow when populating ?
Since I am probably the only one that knows about DAR problem I figured
I should take a stab at it. This is not tested, but I hope Rex and the list
can do that. Once this works as it should, we can remove all special handling
for 8xx in copy_tofrom_user() and friends.
No sign-off yet, want some confirmation first.
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 4dd38f1..691ebd3 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -774,7 +774,14 @@ restore:
lwz r11,_CTR(r1)
mtspr SPRN_XER,r10
mtctr r11
-
+#ifdef CONFIG_8xx
+ /* Tag DAR with a well know value.
+ * This needs to match head_8xx.S and
+ * do_page_fault()
+ */
+ li r10, 0xf0
+ mtspr SPRN_DAR, r10
+#endif
PPC405_ERR77(0,r1)
BEGIN_FTR_SECTION
lwarx r11,0,r1
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 52ff8c5..418ea96 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -39,6 +39,15 @@
#else
#define DO_8xx_CPU6(val, reg)
#endif
+
+/* DAR needs to be tagged with a known value so that the
+ * DataTLB Miss/Error and do_page_fault() can recognize a
+ * buggy dcbx instruction and workaround the problem.
+ * dcbf, dcbi, dcbst, dcbz instructions do not update DAR
+ * when trapping into a Data TLB Miss/Error. See
+ * DataStoreTLBMiss and DataTLBError for details
+ */
+
__HEAD
_ENTRY(_stext);
_ENTRY(_start);
@@ -428,7 +437,8 @@ DataStoreTLBMiss:
* set. All other Linux PTE bits control the behavior
* of the MMU.
*/
-2: li r11, 0x00f0
+ li r11, 0x00f0
+ mtspr SPRN_DAR, r11 /* Tag DAR */
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x3d80, r3)
mtspr SPRN_MD_RPN, r10 /* Update TLB entry */
@@ -441,7 +451,15 @@ DataStoreTLBMiss:
lwz r3, 8(r0)
#endif
rfi
-
+2:
+ mfspr r10, SPRN_M_TW /* Restore registers */
+ lwz r11, 0(r0)
+ mtcr r11
+ lwz r11, 4(r0)
+#ifdef CONFIG_8xx_CPU6
+ lwz r3, 8(r0)
+#endif
+ b DataAccess
/* This is an instruction TLB error on the MPC8xx. This could be due
* to many reasons, such as executing guarded memory or illegal instruction
* addresses. There is nothing to do but handle a big time error fault.
@@ -492,6 +510,8 @@ DataTLBError:
* assuming we only use the dcbi instruction on kernel addresses.
*/
mfspr r10, SPRN_DAR
+ cmpwi cr0, r10, 0xf0 /* check it DAR holds a tag */
+ beq- 2f
rlwinm r11, r10, 0, 0, 19
ori r11, r11, MD_EVALID
mfspr r10, SPRN_M_CASID
@@ -547,6 +567,7 @@ DataTLBError:
* of the MMU.
*/
li r11, 0x00f0
+ mtspr SPRN_DAR, r11 /* Tag DAR */
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x3d80, r3)
mtspr SPRN_MD_RPN, r10 /* Update TLB entry */
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 7699394..be779b2 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -125,6 +125,32 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
int trap = TRAP(regs);
int is_exec = trap == 0x400;
+#if defined(CONFIG_8xx)
+/*
+ Workarund DTLB Miss/Error, as these do not update DAR
+ for dcbf, dcbi, dcbst, dcbz instructions
+ This relies on every exception tagging DAR with 0xf0
+ before returning (rfi)
+ DAR as passed as address to this function.
+ */
+#define RA(inst) (((inst) & 0x001F0000) >> 16)
+#define RB(inst) (((inst) & 0x0000F800) >> 11)
+ {
+ unsigned long ra, rb, dar, insns;
+
+ if (trap == 0x300 && address == 0xf0) {
+ insns = *((unsigned long *)regs->nip);
+ /* Really check if it is an dcbf, dcbi, dcbst, dcbz insns ? */
+ ra = RA(insns); /* Reg Ra */
+ rb = RB(insns); /* Reg Rb */
+ dar = regs->gpr[rb];
+ if (ra)
+ dar += regs->gpr[ra];
+ /* regs->dar = dar; perhaps */
+ address = dar;
+ }
+ }
+#endif
#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
/*
* Fortunately the bit assignments in SRR1 for an instruction
^ permalink raw reply related
* Re: linux-next: tree build failure
From: roel kluin @ 2009-09-29 9:51 UTC (permalink / raw)
To: Jan Beulich
Cc: sfr, hollisb, linux-kernel, kvm-ppc, linux-next, akpm,
linuxppc-dev
In-Reply-To: <4AC1E15502000078000516B5@vpn.id2.novell.com>
On Tue, Sep 29, 2009 at 11:28 AM, Jan Beulich <jbeulich@novell.com> wrote:
>>>> Hollis Blanchard =A009/29/09 2:00 AM >>>
>>First, I think there is a real bug here, and the code should read like
>>this (to match the comment):
>> =A0 =A0/* type has to be known at build time for optimization */
>>- =A0 =A0BUILD_BUG_ON(__builtin_constant_p(type));
>>+ =A0 =A0BUILD_BUG_ON(!__builtin_constant_p(type));
>>
>>However, I get the same build error *both* ways, i.e.
>>__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or
>>the new BUILD_BUG_ON() macro isn't working...
>
> No, at this point of the compilation process it's neither zero nor one,
> it's simply considered non-constant by the compiler at that stage
> (this builtin is used for optimization, not during parsing, and the
> error gets generated when the body of the function gets parsed,
> not when code gets generated from it).
>
> Jan
then maybe
if(__builtin_constant_p(type))
BUILD_BUG_ON(1);
would work?
Roel
^ permalink raw reply
* Re: linux-next: tree build failure
From: Jan Beulich @ 2009-09-29 9:28 UTC (permalink / raw)
To: sfr, hollisb; +Cc: akpm, linux-next, linuxppc-dev, linux-kernel, kvm-ppc
>>> Hollis Blanchard 09/29/09 2:00 AM >>>
>First, I think there is a real bug here, and the code should read like
>this (to match the comment):
> /* type has to be known at build time for optimization */
>- BUILD_BUG_ON(__builtin_constant_p(type));
>+ BUILD_BUG_ON(!__builtin_constant_p(type));
>
>However, I get the same build error *both* ways, i.e.
>__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or
>the new BUILD_BUG_ON() macro isn't working...
No, at this point of the compilation process it's neither zero nor one,
it's simply considered non-constant by the compiler at that stage
(this builtin is used for optimization, not during parsing, and the
error gets generated when the body of the function gets parsed,
not when code gets generated from it).
Jan
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Joakim Tjernlund @ 2009-09-29 8:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1254212198.5256.0.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 29/09/2009 10:16:38:
>
>
> > hmm, yes. You do get this and mysterious SEGV if you hit the but so does
> > other bugs too so this is probably due to missing invalidation.
> >
> > I suspect that something like below will fix the problem and
> > is the "correct" fix(untested, not even compiled):
>
> Ok but do we also still have to worry about the "unpopulated" TLB
> entries and invalidate them somehow when populating ?
No, this patch is to not populate the MMU with invalid entries at
all. Hopefully you can remove those invalidate 8xx TLBs hacks
you currently have.
Jocke
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Benjamin Herrenschmidt @ 2009-09-29 8:16 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <OF490DC464.F75531A6-ONC1257640.002AC41C-C1257640.002D2820@transmode.se>
> hmm, yes. You do get this and mysterious SEGV if you hit the but so does
> other bugs too so this is probably due to missing invalidation.
>
> I suspect that something like below will fix the problem and
> is the "correct" fix(untested, not even compiled):
Ok but do we also still have to worry about the "unpopulated" TLB
entries and invalidate them somehow when populating ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Joakim Tjernlund @ 2009-09-29 8:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1254208057.5771.7.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 29/09/2009 09:07:37:
>
> On Tue, 2009-09-29 at 08:26 +0200, Joakim Tjernlund wrote:
> > > I've tried sticking tlbil_va() in those places, nothing seems to
> > help.
> > > In some cases userspace is slow, in other cases userspace is faster
> > and
> > > unstable: sometimes commands hang, sometimes I am able to ctrl-c and
> > > and kill it, sometimes I get other strange crashes or falures (so
> > far no
> > > kernel oopses though).
> >
> > This is exactly what you get when the "cache insn does not update DAR"
> > bug hits
> > you.
>
> But then why was it working fine before ? Or it wasn't ?
hmm, yes. You do get this and mysterious SEGV if you hit the but so does
other bugs too so this is probably due to missing invalidation.
I suspect that something like below will fix the problem and
is the "correct" fix(untested, not even compiled):
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 52ff8c5..f579a11 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -428,7 +428,7 @@ DataStoreTLBMiss:
* set. All other Linux PTE bits control the behavior
* of the MMU.
*/
-2: li r11, 0x00f0
+ li r11, 0x00f0
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x3d80, r3)
mtspr SPRN_MD_RPN, r10 /* Update TLB entry */
@@ -441,7 +441,23 @@ DataStoreTLBMiss:
lwz r3, 8(r0)
#endif
rfi
+2:
+ /* Copy 20 msb from MD_EPN to DAR since the dcxx instructions fails
+ * to update DAR when they cause a DTLB Miss.
+ */
+ mfspr r11, SPRN_MD_EPN
+ mfspr r10, SPRN_DAR
+ rlwimi r10, r11, 0, 0, 19
+ mtspr SPRN_DAR, r10
+ mfspr r10, SPRN_M_TW /* Restore registers */
+ lwz r11, 0(r0)
+ mtcr r11
+ lwz r11, 4(r0)
+#ifdef CONFIG_8xx_CPU6
+ lwz r3, 8(r0)
+#endif
+ b DataAccess
/* This is an instruction TLB error on the MPC8xx. This could be due
* to many reasons, such as executing guarded memory or illegal instruction
* addresses. There is nothing to do but handle a big time error fault.
^ permalink raw reply related
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Benjamin Herrenschmidt @ 2009-09-29 7:07 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <OF1870F4D5.BB673882-ONC1257640.00233638-C1257640.00236DC9@transmode.se>
On Tue, 2009-09-29 at 08:26 +0200, Joakim Tjernlund wrote:
> > I've tried sticking tlbil_va() in those places, nothing seems to
> help.
> > In some cases userspace is slow, in other cases userspace is faster
> and
> > unstable: sometimes commands hang, sometimes I am able to ctrl-c and
> > and kill it, sometimes I get other strange crashes or falures (so
> far no
> > kernel oopses though).
>
> This is exactly what you get when the "cache insn does not update DAR"
> bug hits
> you.
But then why was it working fine before ? Or it wasn't ?
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Benjamin Herrenschmidt @ 2009-09-29 7:07 UTC (permalink / raw)
To: Rex Feany; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20090929012106.GA22798@compile2.chatsunix.int.mrv.com>
On Mon, 2009-09-28 at 18:21 -0700, Rex Feany wrote:
> > It's going to be hard for me to get that "right" since I don't really
> > know what's going on with the core here, but I suppose if we get it
> > moving along with extra tlb invalidations, that should be "good enough"
> > until somebody who really knows what's going on comes up with possibly
> > a better fix.
>
> I've tried sticking tlbil_va() in those places, nothing seems to help.
> In some cases userspace is slow, in other cases userspace is faster and
> unstable: sometimes commands hang, sometimes I am able to ctrl-c and
> and kill it, sometimes I get other strange crashes or falures (so far no
> kernel oopses though).
And you are positive that with 2.6.31 and your other patch, it works
both fast and stable ? This is strange... the code should be mostly
identical. I'll have a second look and see if I can get you a patch that
reproduce -exactly- the behaviour of 2.6.31 plus your patch.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v4] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570
From: Richard Röjfors @ 2009-09-29 6:34 UTC (permalink / raw)
To: John Linn; +Cc: spi-devel-general, Andrew Morton, dbrownell, linuxppc-dev
In-Reply-To: <8741a4f8-b490-4754-a674-71ea2ee1385a@SG2EHSMHS011.ehs.local>
On 9/28/09 5:41 PM, John Linn wrote:
>> -----Original Message-----
>> From: Richard Röjfors [mailto:richard.rojfors@mocean-labs.com]
>> Sent: Monday, September 28, 2009 8:22 AM
>> To: spi-devel-general@lists.sourceforge.net
>> Cc: linuxppc-dev@ozlabs.org; dbrownell@users.sourceforge.net; Andrew Morton; John Linn
>> Subject: [PATCH v4] xilinx_spi: Splitted into generic, of and platform driver, added support for
>> DS570
>>
>> This patch splits xilinx_spi into three parts, an OF and a platform
>> driver and generic part.
>>
>> The generic part now also works on X86, it supports accessing the IP
>> booth big and little endian. There is also support for 16 and 32 bit
>> SPI for the Xilinx SPI IP DS570
>>
>> Signed-off-by: Richard Röjfors <richard.rojfors@mocean-labs.com>
>> ---
>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>> index 2c733c2..ecabc12 100644
>> --- a/drivers/spi/Kconfig
>> +++ b/drivers/spi/Kconfig
>> @@ -218,8 +218,8 @@ config SPI_TXX9
>> SPI driver for Toshiba TXx9 MIPS SoCs
>>
>
> <snip>
>
>>
>> -struct xilinx_spi {
>> - /* bitbang has to be first */
>> - struct spi_bitbang bitbang;
>> - struct completion done;
>> +/* to follow are some functions that does little of big endian read and
>> + * write depending on the config of the device.
>> + */
>> +static inline void xspi_write8(struct xilinx_spi *xspi, u32 offs, u8 val)
>> +{
>> + iowrite8(val, xspi->regs + offs + ((xspi->big_endian) ? 3 : 0));
>> +}
>>
>> - void __iomem *regs; /* virt. address of the control registers */
>> +static inline void xspi_write16(struct xilinx_spi *xspi, u32 offs, u16 val)
>> +{
>> + if (xspi->big_endian)
>> + iowrite16be(val, xspi->regs + offs + 2);
>> + else
>> + iowrite16(val, xspi->regs + offs);
>> +}
>
>
> Hi Richard,
Hi John,
Thanks for the quick feedback.
> If you're worried about efficiency (the reason for 16 and 32 bit xfers), why wouldn't you do the big-endian vs little endian I/O decision at compile time rather than run time?
I'm afraid we can't do it compile time, if we want to be flexible. As
example;
The IP is big endian, in our case the PCI interface flips the byte
order. But the PCI interface might be setup differently ->would be
accessed big endian even on a little endian machine.
We could use callbacks set up during probe, instead of having the
if-sentence. But I don't think the callback solution could be slower (if
talking performance), since the compiler can't inline them, the current
functions could be inlined if the compiler feels like it.
> The big_endian variable is not a constant boolean, I don't know if that could help so that the compiler optimizes this check away? Or maybe it is already and I'm just missing that?
>
>>
>> - u32 irq;
>> +static inline void xspi_write32(struct xilinx_spi *xspi, u32 offs, u32 val)
>> +{
>> + if (xspi->big_endian)
>> + iowrite32be(val, xspi->regs + offs);
>> + else
>> + iowrite32(val, xspi->regs + offs);
>> +}
>>
>> - u32 speed_hz; /* SCK has a fixed frequency of speed_hz Hz */
>> +static inline u8 xspi_read8(struct xilinx_spi *xspi, u32 offs)
>> +{
>> + return ioread8(xspi->regs + offs + ((xspi->big_endian) ? 3 : 0));
>> +}
>>
>> - u8 *rx_ptr; /* pointer in the Tx buffer */
>> - const u8 *tx_ptr; /* pointer in the Rx buffer */
>> - int remaining_bytes; /* the number of bytes left to transfer */
>> -};
>
> <snip>
>
>> -
>> /* This driver supports single master mode only. Hence Tx FIFO Empty
>> * is the only interrupt we care about.
>> * Receive FIFO Overrun, Transmit FIFO Underrun, Mode Fault, and Slave Mode
>> @@ -237,32 +298,50 @@ static irqreturn_t xilinx_spi_irq(int irq, void *dev_id)
>> u32 ipif_isr;
>>
>> /* Get the IPIF interrupts, and clear them immediately */
>> - ipif_isr = in_be32(xspi->regs + XIPIF_V123B_IISR_OFFSET);
>> - out_be32(xspi->regs + XIPIF_V123B_IISR_OFFSET, ipif_isr);
>> + ipif_isr = xspi_read32(xspi, XIPIF_V123B_IISR_OFFSET);
>> + xspi_write32(xspi, XIPIF_V123B_IISR_OFFSET, ipif_isr);
>>
>> if (ipif_isr & XSPI_INTR_TX_EMPTY) { /* Transmission completed */
>> u16 cr;
>> u8 sr;
>> + u8 rsize;
>> + if (xspi->bits_per_word == 8)
>> + rsize = 1;
>> + else if (xspi->bits_per_word == 16)
>> + rsize = 2;
>> + else
>> + rsize = 4;
>>
>> /* A transmit has just completed. Process received data and
>> * check for more data to transmit. Always inhibit the
>> * transmitter while the Isr refills the transmit register/FIFO,
>> * or make sure it is stopped if we're done.
>> */
>> - cr = in_be16(xspi->regs + XSPI_CR_OFFSET);
>> - out_be16(xspi->regs + XSPI_CR_OFFSET,
>> - cr | XSPI_CR_TRANS_INHIBIT);
>> + cr = xspi_read16(xspi, XSPI_CR_OFFSET);
>> + xspi_write16(xspi, XSPI_CR_OFFSET, cr | XSPI_CR_TRANS_INHIBIT);
>>
>> /* Read out all the data from the Rx FIFO */
>> - sr = in_8(xspi->regs + XSPI_SR_OFFSET);
>> + sr = xspi_read8(xspi, XSPI_SR_OFFSET);
>> while ((sr & XSPI_SR_RX_EMPTY_MASK) == 0) {
>> - u8 data;
>> + u32 data;
>> + if (rsize == 1)
>> + data = xspi_read8(xspi, XSPI_RXD_OFFSET);
>> + else if (rsize == 2)
>> + data = xspi_read16(xspi, XSPI_RXD_OFFSET);
>> + else
>> + data = xspi_read32(xspi, XSPI_RXD_OFFSET);
>>
>> - data = in_8(xspi->regs + XSPI_RXD_OFFSET);
>> if (xspi->rx_ptr) {
>> - *xspi->rx_ptr++ = data;
>> + if (rsize == 1)
>> + *xspi->rx_ptr = data & 0xff;
>> + else if (rsize == 2)
>> + *(u16 *)(xspi->rx_ptr) = data & 0xffff;
>> + else
>> + *((u32 *)(xspi->rx_ptr)) = data;
>> + xspi->rx_ptr += rsize;
>
> Maybe I'm out of line here...
>
> I'm wondering if this is going to be any more efficient that just using 8 bit accesses
We can not do 8 bit accesses if the IP is set up to do 16/32bit SPI,
then the TX/RX registers are as wide as the bit setup.
We could do 32 bit reads from the registers, then we waste some cycles
on the PLB bus, but have slightly simpler code.
> as it seems like the amount of run-time decisions being made is quite a few. I guess it depends on how many bytes are being transferred as with big transfers maybe it will pay off.
>
> In my opinion, which isn't worth much many times :), sometimes the flexibility with soft logic, like this is a pain for testability and increases complexity. If there's reasonable performance gains then maybe it's a good tradeoff.
>
> Do you know how much performance gain there is or is expected as maybe you've seen the pay off already?
I haven't done any measurements, and we are basically only controlling
GPIO so performance is not an issue for us. I just didn't want do make
it slower. I think you have more experience here. Do you think it's
better to just do 32bit reads to make the code simple? If so I will
update the code.
Thanks
--Richard
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Joakim Tjernlund @ 2009-09-29 6:26 UTC (permalink / raw)
To: Rex Feany; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20090929012106.GA22798@compile2.chatsunix.int.mrv.com>
>
> Thus spake Benjamin Herrenschmidt (benh@kernel.crashing.org):
>
> > On Thu, 2009-09-24 at 18:35 -0700, Rex Feany wrote:
> > >
> > > Then I can boot and get to a shell, but userspace is slow. 8 seconds
> > > to mount
> > > /proc (vs. less then a second using my old kernel)! Maybe this is an
> > > unrelated issue? I'm pretty clueless about the details, I'm sorry.
> > > PG_arch_1 is used to prevent a cache flush unless it is actually
> > > needed?
> > > Then why would changing the location of the tlbil_va() make a
> > > difference?
> >
> > I think there's more finishyness to 8xx than we thought. IE. That
> > tlbil_va might have more reasons to be there than what the comment
> > seems to advertize. Can you try to move it even higher up ? IE.
> > Unconditionally at the beginning of set_pte_filter ?
> >
> > Also, if that doesn't help, can you try putting one in
> > set_access_flags_filter() just below ?
> >
> > (Beware that there's two different versions of both functions, only the
> > first one is compiled/used on 8xx).
> >
> > It's going to be hard for me to get that "right" since I don't really
> > know what's going on with the core here, but I suppose if we get it
> > moving along with extra tlb invalidations, that should be "good enough"
> > until somebody who really knows what's going on comes up with possibly
> > a better fix.
>
> I've tried sticking tlbil_va() in those places, nothing seems to help.
> In some cases userspace is slow, in other cases userspace is faster and
> unstable: sometimes commands hang, sometimes I am able to ctrl-c and
> and kill it, sometimes I get other strange crashes or falures (so far no
> kernel oopses though).
This is exactly what you get when the "cache insn does not update DAR" bug hits
you.
^ permalink raw reply
* Re: Market research for new PowerPC system
From: Brian Morris @ 2009-09-29 3:46 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Konstantinos Margaritis, debian-powerpc, linuxppc-dev,
opensuse-ppc
In-Reply-To: <Pine.LNX.4.64.0909261949240.4273@axis700.grange>
[-- Attachment #1: Type: text/plain, Size: 7025 bytes --]
I think that you should start out with something of the sub-netbook type.
These are the next generation and coming up very soon. For a home computer
you need at least dual core and at those speeds it will need a very low
price and small footprint.
If you could sneak in on the sub-net quick perhaps power could become 2nd to
ARM as AMD is to Intel. Intel is trying to sneak in but there could be some
anti-trust issues, especially if there are other contenders (maybe).
Its really too too bad PA-SEMI killed by apple last year. I am still mad
about that. That was a really really nice cpu, 2ghz and 7watt and 64bit.
Should have been illegal.
The first subnetbook may likely be an apple product, and a tablet with an
optional separate keyboard and a 9.5 inch screen, and the ARM cpu...
On Sat, Sep 26, 2009 at 10:58 AM, Guennadi Liakhovetski <
g.liakhovetski@gmx.de> wrote:
> On Sat, 26 Sep 2009, Konstantinos Margaritis wrote:
>
> > (Sorry for the cross-posting, please ignore if you are not interested in
> this,
> > CC me as I'm not subscribed)
> > Hi,
> >
> > First some introductions. I'm Konstantinos Margaritis, a long time
> > Amiga/BeOS/Linux user/developer and a PowerPC fan, former Debian
> Developer,
> > also a SIMD/AltiVec fanatic and the author of libfreevec. I've posted
> this on
> > the following sites:
> >
> >
> http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=29594&forum=33&start=0&viewmode=flat&order=0
> >
> > http://www.amiga.org/forums/showthread.php?t=49424
> >
> >
> http://www.morphzone.org/modules/newbb_plus/viewtopic.php?topic_id=6465&forum=11
> >
> >
> http://aros-exec.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=3768&forum=4
> >
> >
> http://www.haiku-os.org/community/forum/market_research_new_powerpc_system#comment-12604
> >
> > To anyone who is not a PowerPC user, it might seem like crazy, but here
> it
> > goes:
> >
> > I'm considering funding the design & production of a new PowerPC system
> (well,
> > the motherboard, the rest are typical pc stuff and a case). No this is
> not a
> > joke, I've been wanting to do this for a long time, and perhaps the
> chance
> > will be given to me now. But before I spend any money on this, I want to
> do a
> > little market research first. I know the market is literally "dying" for
> a new
> > powerpc motherboard, but exactly how many are there that want to buy one?
>
> Ok, just a short comment. In principle I like diversity, competition, etc.
> And it was somewhat sad when Apple abandoned ppc. But honestly - why
> should I be buying a ppc desktop system? If we restrict our comparison to
> Linux, because that's what I'm using, what advantages would a ppc system
> give me over a comparable in price ix86 system? This is not meant
> negatively, I just have not followed recent ppc CPUs from the "desktop"
> range, so, this is a real honest question. Would such a system provide
> more MIPS per Watt at the same price? Or more periferals? Or some specific
> hardware blocks unavailable or unsupported om ix86?
>
> Thanks
> Guennadi
>
> >
> > Ok, let's give some rough specs first. I'm considering 3 choices -not in
> order
> > of probability/importance:
> >
> > 1. MPC8640D-based. It will be dual core at 1Ghz -most likely, higher
> > frequencies are much more expensive and the cost of the final board would
> be
> > prohibitive.
> > 2. MPC8610-based. Single core at 1Ghz, slightly less expensive, and
> includes a
> > 2D DIU display unit -quite fast, but no 3D unfortunately.
> > 3. QorIQ P1022-based. Again dual core at 1Ghz (1055Mhz to be precise).
> Apart
> > from the much lower chip price, this one includes dual gigabit ethernet,
> dual
> > SATA, USB 2.0 and a 2D DIU display unit (same as the MPC8610). So this
> one
> > would lower the cost of the board quite much. Disadvantages: No AltiVec
> unit
> > (it sucks I know), though it includes an SPE unit which is not that bad,
> and
> > availability will be in Q3/Q4 2010, so that's a long wait.
> >
> > Now, the end motherboard will probably be MicroATX (in the 8640D/8610
> case) or
> > PicoITX (in the P1022 case), and it will definitely include:
> >
> > * SATA connectors
> > * USB (possibly 2 back and 2 front, but that's discussable)
> > * Dual gigabit (at least one will be there, in the case of the MPC8640D
> we
> > might even have 4!!!)
> > * Sound (of course, SPDIF support will definitely be there)
> > * 1 PCI-e slot 1x
> > * 1 PCI-e slot (4x in the P1022 case, 8x in the MPC86xx cases)
> >
> > Ok, what I want to know is if people would really really buy one of
> these. End
> > price is estimated to be ~around~ 350EUR for the P1022 board or ~500EUR
> > (definitely more in the case of 8640D) in the case of the other boards.
> > Besides being more expensive, the MPC86xx chips, don't include SATA, USB
> and
> > only one of ethernet/sound (quad-gige in MPC8640D case, or sound in the
> case
> > of MPC8610). I know this sounds a lot, but it's the reality, there is not
> > enough funding to build enormous amounts of units and bring the prices
> down
> > substantially, we have to start low and build up from there. In case you
> are
> > wondering, yes, the boards will be designed/produced by bPlan and funded
> by my
> > company (Codex).
> >
> > Support for OSes: Linux definitely, Haiku most probably and there is a
> > possibility of supporting AmigaOS/MorphOS, which will depend on the
> actual
> > feedback I get from those users.
> >
> > I would like to make a list of everyone that is really interested in such
> a
> > system, so it would really help me make a decision sooner rather than
> later if
> > you would send me a few personal details to markos@codex.gr with subject
> > "PowerPC board":
> >
> > * Name
> > * Country
> > * email (definitely, I'd have to reach you back!)
> > * Phone/Skype (optional, please include international prefix)
> > * Forum you saw this post (ok, Morphzone in this case)
> > * OS of preference
> > * board you would be most interested in (MPC8610/MPC8640D/P1022)
> > * preferred price (please have in mind the estimated price quotes I
> mentioned,
> > it might be lower but that's not very probable)
> > * Other notes/comments
> >
> > Also, I found out that I had to state my case on many forums to prove
> that
> > this is not vapourware. Well, it will not be vapourware, if I get
> feedback. So
> > far the feedback I got can be summarized here:
> >
> > http://www.codex.gr/index.php?pageID=&blogItem=60
> >
> > Thanks a lot for your time and I hope this system becomes a reality.
> >
> > Konstantinos Margaritis
> >
> > Codex
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>
>
> --
> To UNSUBSCRIBE, email to debian-powerpc-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
[-- Attachment #2: Type: text/html, Size: 9183 bytes --]
^ permalink raw reply
* Re: Market research for new PowerPC system
From: Chris "Bigguy" @ 2009-09-29 3:45 UTC (permalink / raw)
To: Konstantinos Margaritis, Chris Friesen
Cc: debian-powerpc, linuxppc-dev, opensuse-ppc
In-Reply-To: <4AC14047.30501@nortel.com>
Speaking for myself, and I'm a small-time consultant to the local Small-Off=
ice Home-Office market, I would wholeheartedly welcome the arrival to the m=
arket of a PowerPC/Power motherboard. I would commission local builders to=
create servers and desktops that would have that one extra layer of protec=
tion from malware.=0A=0AI believe it would also give developers a platform =
to hone their skills on a native platform for the embedded market.=0A=0AI w=
holeheartedly endorse the creation of a PowerPC/POWER motherboard. I'll be=
one of the first customers.=0A=0AAll my best - Chris Reich; Rochester, New=
York=0A=0A=0A=0A--- On Mon, 9/28/09, Chris Friesen <cfriesen@nortel.com> w=
rote:=0A=0A> From: Chris Friesen <cfriesen@nortel.com>=0A> Subject: Re: Mar=
ket research for new PowerPC system=0A> To: "Konstantinos Margaritis" <mark=
os@codex.gr>=0A> Cc: linuxppc-dev@lists.ozlabs.org, debian-powerpc@lists.de=
bian.org, opensuse-ppc@opensuse.org=0A> Date: Monday, September 28, 2009, 7=
:01 PM=0A> On 09/26/2009 05:38 AM, Konstantinos=0A> Margaritis wrote:=0A> =
=0A> > I'm considering funding the design & production of=0A> a new PowerPC=
=A0 =0A> > system (well, the motherboard, the rest are typical pc=0A> stuff=
and a=A0 =0A> > case).=0A> =0A> It might be interesting as a low-power sys=
tem.=A0 For a=0A> development box,=0A> this looks more interesting:=0A> =0A=
> http://www.fixstars.com/en/products/powerstation/specs.html=0A> =0A> $125=
0 USD gets you two dual-core 2.5GHz 970MP chips.=0A> =0A> Chris=0A> =0A> =
=0A> -- =0A> To UNSUBSCRIBE, email to debian-powerpc-REQUEST@lists.debian.o=
rg=0A> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.d=
ebian.org=0A> =0A>
^ permalink raw reply
* Re: Market research for new PowerPC system
From: Brian Morris @ 2009-09-29 3:54 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Konstantinos Margaritis, debian-powerpc, linuxppc-dev,
opensuse-ppc
In-Reply-To: <Pine.LNX.4.64.0909261949240.4273@axis700.grange>
[-- Attachment #1: Type: text/plain, Size: 6781 bytes --]
one other idea (sorry)
Debian is not providing an altivec optimized version. If you want that you
have to go with Gentoo. If you were building cpu optimized from the ground
up with the libaltivec and perhaps the c++ altivec libraries (that require
translation for the changed library calls to all the source codes that use
them -- ughh) -- it would be a lot more interesting. I've thought about
doing the Gentoo but its a lot of compiling, especially on slower cpus (I've
had some experience with fink and macports in MacOSX which want that too)
On Sat, Sep 26, 2009 at 10:58 AM, Guennadi Liakhovetski <
g.liakhovetski@gmx.de> wrote:
> On Sat, 26 Sep 2009, Konstantinos Margaritis wrote:
>
> > (Sorry for the cross-posting, please ignore if you are not interested in
> this,
> > CC me as I'm not subscribed)
> > Hi,
> >
> > First some introductions. I'm Konstantinos Margaritis, a long time
> > Amiga/BeOS/Linux user/developer and a PowerPC fan, former Debian
> Developer,
> > also a SIMD/AltiVec fanatic and the author of libfreevec. I've posted
> this on
> > the following sites:
> >
> >
> http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=29594&forum=33&start=0&viewmode=flat&order=0
> >
> > http://www.amiga.org/forums/showthread.php?t=49424
> >
> >
> http://www.morphzone.org/modules/newbb_plus/viewtopic.php?topic_id=6465&forum=11
> >
> >
> http://aros-exec.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=3768&forum=4
> >
> >
> http://www.haiku-os.org/community/forum/market_research_new_powerpc_system#comment-12604
> >
> > To anyone who is not a PowerPC user, it might seem like crazy, but here
> it
> > goes:
> >
> > I'm considering funding the design & production of a new PowerPC system
> (well,
> > the motherboard, the rest are typical pc stuff and a case). No this is
> not a
> > joke, I've been wanting to do this for a long time, and perhaps the
> chance
> > will be given to me now. But before I spend any money on this, I want to
> do a
> > little market research first. I know the market is literally "dying" for
> a new
> > powerpc motherboard, but exactly how many are there that want to buy one?
>
> Ok, just a short comment. In principle I like diversity, competition, etc.
> And it was somewhat sad when Apple abandoned ppc. But honestly - why
> should I be buying a ppc desktop system? If we restrict our comparison to
> Linux, because that's what I'm using, what advantages would a ppc system
> give me over a comparable in price ix86 system? This is not meant
> negatively, I just have not followed recent ppc CPUs from the "desktop"
> range, so, this is a real honest question. Would such a system provide
> more MIPS per Watt at the same price? Or more periferals? Or some specific
> hardware blocks unavailable or unsupported om ix86?
>
> Thanks
> Guennadi
>
> >
> > Ok, let's give some rough specs first. I'm considering 3 choices -not in
> order
> > of probability/importance:
> >
> > 1. MPC8640D-based. It will be dual core at 1Ghz -most likely, higher
> > frequencies are much more expensive and the cost of the final board would
> be
> > prohibitive.
> > 2. MPC8610-based. Single core at 1Ghz, slightly less expensive, and
> includes a
> > 2D DIU display unit -quite fast, but no 3D unfortunately.
> > 3. QorIQ P1022-based. Again dual core at 1Ghz (1055Mhz to be precise).
> Apart
> > from the much lower chip price, this one includes dual gigabit ethernet,
> dual
> > SATA, USB 2.0 and a 2D DIU display unit (same as the MPC8610). So this
> one
> > would lower the cost of the board quite much. Disadvantages: No AltiVec
> unit
> > (it sucks I know), though it includes an SPE unit which is not that bad,
> and
> > availability will be in Q3/Q4 2010, so that's a long wait.
> >
> > Now, the end motherboard will probably be MicroATX (in the 8640D/8610
> case) or
> > PicoITX (in the P1022 case), and it will definitely include:
> >
> > * SATA connectors
> > * USB (possibly 2 back and 2 front, but that's discussable)
> > * Dual gigabit (at least one will be there, in the case of the MPC8640D
> we
> > might even have 4!!!)
> > * Sound (of course, SPDIF support will definitely be there)
> > * 1 PCI-e slot 1x
> > * 1 PCI-e slot (4x in the P1022 case, 8x in the MPC86xx cases)
> >
> > Ok, what I want to know is if people would really really buy one of
> these. End
> > price is estimated to be ~around~ 350EUR for the P1022 board or ~500EUR
> > (definitely more in the case of 8640D) in the case of the other boards.
> > Besides being more expensive, the MPC86xx chips, don't include SATA, USB
> and
> > only one of ethernet/sound (quad-gige in MPC8640D case, or sound in the
> case
> > of MPC8610). I know this sounds a lot, but it's the reality, there is not
> > enough funding to build enormous amounts of units and bring the prices
> down
> > substantially, we have to start low and build up from there. In case you
> are
> > wondering, yes, the boards will be designed/produced by bPlan and funded
> by my
> > company (Codex).
> >
> > Support for OSes: Linux definitely, Haiku most probably and there is a
> > possibility of supporting AmigaOS/MorphOS, which will depend on the
> actual
> > feedback I get from those users.
> >
> > I would like to make a list of everyone that is really interested in such
> a
> > system, so it would really help me make a decision sooner rather than
> later if
> > you would send me a few personal details to markos@codex.gr with subject
> > "PowerPC board":
> >
> > * Name
> > * Country
> > * email (definitely, I'd have to reach you back!)
> > * Phone/Skype (optional, please include international prefix)
> > * Forum you saw this post (ok, Morphzone in this case)
> > * OS of preference
> > * board you would be most interested in (MPC8610/MPC8640D/P1022)
> > * preferred price (please have in mind the estimated price quotes I
> mentioned,
> > it might be lower but that's not very probable)
> > * Other notes/comments
> >
> > Also, I found out that I had to state my case on many forums to prove
> that
> > this is not vapourware. Well, it will not be vapourware, if I get
> feedback. So
> > far the feedback I got can be summarized here:
> >
> > http://www.codex.gr/index.php?pageID=&blogItem=60
> >
> > Thanks a lot for your time and I hope this system becomes a reality.
> >
> > Konstantinos Margaritis
> >
> > Codex
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>
>
> --
> To UNSUBSCRIBE, email to debian-powerpc-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
[-- Attachment #2: Type: text/html, Size: 8892 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Rex Feany @ 2009-09-29 1:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1253843480.7103.492.camel@pasglop>
Thus spake Benjamin Herrenschmidt (benh@kernel.crashing.org):
> On Thu, 2009-09-24 at 18:35 -0700, Rex Feany wrote:
> >
> > Then I can boot and get to a shell, but userspace is slow. 8 seconds
> > to mount
> > /proc (vs. less then a second using my old kernel)! Maybe this is an
> > unrelated issue? I'm pretty clueless about the details, I'm sorry.
> > PG_arch_1 is used to prevent a cache flush unless it is actually
> > needed?
> > Then why would changing the location of the tlbil_va() make a
> > difference?
>
> I think there's more finishyness to 8xx than we thought. IE. That
> tlbil_va might have more reasons to be there than what the comment
> seems to advertize. Can you try to move it even higher up ? IE.
> Unconditionally at the beginning of set_pte_filter ?
>
> Also, if that doesn't help, can you try putting one in
> set_access_flags_filter() just below ?
>
> (Beware that there's two different versions of both functions, only the
> first one is compiled/used on 8xx).
>
> It's going to be hard for me to get that "right" since I don't really
> know what's going on with the core here, but I suppose if we get it
> moving along with extra tlb invalidations, that should be "good enough"
> until somebody who really knows what's going on comes up with possibly
> a better fix.
I've tried sticking tlbil_va() in those places, nothing seems to help.
In some cases userspace is slow, in other cases userspace is faster and
unstable: sometimes commands hang, sometimes I am able to ctrl-c and
and kill it, sometimes I get other strange crashes or falures (so far no
kernel oopses though).
take care!
/rex.
^ permalink raw reply
* Re: warning: allocated section `.data_nosave' not in segment
From: Segher Boessenkool @ 2009-09-29 0:29 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20090928192454.4dc937c9@lappy.seanm.ca>
> Here is the ld -M output for the "bad" compile:
>
> .data_nosave 0xc0376790 0x870 load address 0x00376790
> 0xc0377000 . = ALIGN (0x1000)
> *fill* 0xc0376790 0x870 00
Ah right. Having the ALIGN() inside the output section causes the linker
to put some filler in there, which makes it a non-empty section, but this
section isn't assigned to a segment so you get a warning from the linker.
I think the proper way to do this is to not put the ALIGN() before the
output section, nor inside it, but _on_ it, like
.data_nosave : ALIGN(0x1000) { .... }
Segher
^ permalink raw reply
* Re: linux-next: tree build failure
From: Hollis Blanchard @ 2009-09-29 0:00 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-kernel, kvm-ppc, linux-next, Jan Beulich, Andrew Morton,
ppc-dev
In-Reply-To: <20090924152102.8d7d40cf.sfr@canb.auug.org.au>
On Thu, 2009-09-24 at 15:21 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
>
> In file included from arch/powerpc/kvm/booke.c:31:
> arch/powerpc/kvm/timing.h: In function 'kvmppc_account_exit_stat':
> arch/powerpc/kvm/timing.h:51: error: bit-field '<anonymous>' width not an integer constant
> In file included from arch/powerpc/kvm/booke.h:26,
> from arch/powerpc/kvm/booke_emulate.c:23:
> arch/powerpc/kvm/timing.h: In function 'kvmppc_account_exit_stat':
> arch/powerpc/kvm/timing.h:51: error: bit-field '<anonymous>' width not an integer constant
>
> Presumably caused by commit 8c87df457cb58fe75b9b893007917cf8095660a0
> ("BUILD_BUG_ON(): fix it and a couple of bogus uses of it").
First, I think there is a real bug here, and the code should read like
this (to match the comment):
/* type has to be known at build time for optimization */
- BUILD_BUG_ON(__builtin_constant_p(type));
+ BUILD_BUG_ON(!__builtin_constant_p(type));
However, I get the same build error *both* ways, i.e.
__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or
the new BUILD_BUG_ON() macro isn't working...
> I applied the following patch for today. This inline function is
> only called from one place in one file ...
It's also called via kvmppc_account_exit() from a number of places.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: warning: allocated section `.data_nosave' not in segment
From: Sean MacLennan @ 2009-09-28 23:24 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <903BCD86-DE53-48AB-89CF-78248D7F6115@kernel.crashing.org>
Here is the ld -M output for the "bad" compile:
.data_nosave 0xc0376790 0x870 load address 0x00376790
0xc0377000 . = ALIGN (0x1000)
*fill* 0xc0376790 0x870 00
0xc0377000 __nosave_begin = .
*(.data.nosave)
0xc0377000 . = ALIGN (0x1000)
0xc0377000 __nosave_end = .
0xc0377000 . = ALIGN (0x1000)
0xc0377000 _edata = .
0xc0377000 PROVIDE (edata, .)
0xc0377000 . = ALIGN (0x0)
0xc0377000 __bss_start = .
0xc0377000 . = ALIGN (0x0)
.sbss 0xc0377000 0xad0 load address 0x00377000
Here is the ld -M output for a "good" compile (i.e. align before
the .data_nosave:
0xc0377000 . = ALIGN (0x1000)
.data_nosave 0xc0377000 0x0 load address 0x00377000
0xc0377000 __nosave_begin = .
*(.data.nosave)
0xc0377000 . = ALIGN (0x1000)
0xc0377000 __nosave_end = .
0xc0377000 . = ALIGN (0x1000)
0xc0377000 _edata = .
0xc0377000 PROVIDE (edata, .)
0xc0377000 . = ALIGN (0x0)
0xc0377000 __bss_start = .
0xc0377000 . = ALIGN (0x0)
.sbss 0xc0377000 0xad0 load address 0x00377000
It looks like putting the align before the .data.nosave puts all the
labels at the same address. Putting it *after* allows the .data_nosave
to be in a different page than the labels.
I can provide more info if needed. But it looks like everything is
nicely aligned, until the data_nosave, which needs the alignment. The
section before it is one of the few with stuff in it.
Cheers,
Sean
^ permalink raw reply
* Re: Market research for new PowerPC system
From: Chris Friesen @ 2009-09-28 23:01 UTC (permalink / raw)
To: Konstantinos Margaritis; +Cc: debian-powerpc, linuxppc-dev, opensuse-ppc
In-Reply-To: <0046254A-432D-4AE3-9B9F-C0D30311B7D7@codex.gr>
On 09/26/2009 05:38 AM, Konstantinos Margaritis wrote:
> I'm considering funding the design & production of a new PowerPC
> system (well, the motherboard, the rest are typical pc stuff and a
> case).
It might be interesting as a low-power system. For a development box,
this looks more interesting:
http://www.fixstars.com/en/products/powerstation/specs.html
$1250 USD gets you two dual-core 2.5GHz 970MP chips.
Chris
^ permalink raw reply
* Re: warning: allocated section `.data_nosave' not in segment
From: Segher Boessenkool @ 2009-09-28 20:56 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20090928115316.7e0b7db9@lappy.seanm.ca>
> If you ignore the VMLINUX_SYMBOL, the only difference is moving the
> ALIGN inside the brackets. If I move the ALIGN back where it was, then
> the warning goes away.
>
> But other sections moved the ALIGN without an issue. Could it be a
> compiler problem? We are using version 4.0.0 (DENX ELDK 4.1 4.0.0).
The compiler version is probably not relevant; the binutils versions
might be though. But, it seems to me the patch was simply botched,
the ALIGN() should not have moved.
Look at the output of "ld -M" (the ld command with all the args that
are used during the compile, with -M added) to see what's up; or maybe
readelf can tell you already.
Segher
^ 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