* Re: Kernel for MPC Lite 5200 will not compile
From: Dale Farnsworth @ 2006-03-30 20:05 UTC (permalink / raw)
To: jcrigby, Linuxppc-embedded
In-Reply-To: <4b73d43f0603300839k4465b2aao7e073f83052b97ff@mail.gmail.com>
Jon Rigby <jcrigby@gmail.com> wrote:
> After thinking about this more....I don't want to push getting the official
> Freescale code into the tree. If Dale's code works as well as the Freescale
> code then lets stay with it because it is a lot cleaner.
Thanks.
> The effort of porting other drivers will hopefully be easier now that
> I have the experience of having done ATA.
Would Freescale be amenable to working toward a revised, common, API?
Unfortunately, I didn't find the Freescale Bestcomm API to be clean enough
for acceptance into Linux, so changes would be needed.
-Dale
^ permalink raw reply
* Re: Kernel for MPC Lite 5200 will not compile
From: Dale Farnsworth @ 2006-03-30 19:53 UTC (permalink / raw)
To: jcrigby, Linuxppc-embedded
In-Reply-To: <4b73d43f0603300829q7d45a029qdb5d8006ccda7275@mail.gmail.com>
John Rigby <jcrigby@gmail.com> wrote:
> Sent this to Wolfgang last night. Accidently omitted Syvain and the list.
>
> The actual bestcomm "microcode" in Sylvain's tree is the same as the latest
> Freescale supported code. The linux driver code that interfaces with it is
> code written by Dale Farnsworth and has Montavista copyright. I don't know
> if it is based on old Freescale (Motorola) code or if it is Dale's creation
> (perhaps Dale can comment).
My bestcomm code is not based on the Freescale code. I did have access to
the Freescale (Motorola) code when I wrote it, but I think you'll find that
there is *very little* similarity between the two code bases.
> I have just spent some time getting UDMA support into the ATA driver using
> the the bestcomm code in Sylvain's tree. In the process I found some bugs
> in the code that may explain some problems people have seen with the FEC
> driver. I'll try to get the patch out tomorrow.
>
> The ATA driver is a port from a version that worked on an older kernel and
> used the supported Freescale Bestcomm code. I did the port because it was
> my understanding that attempts to get the supported Freescale code into a
> public tree had met with resistance in the past. (Second hand info, I'm
> actually fairly new to the 52xx world).
>
> The pluses for the Freescale version is that several devices are supported
> that are not in Sylvain's tree. The version in Sylvain's kernel has a
> generic api plus specific code for FEC. My upcoming patch fixes some bugs,
> adds some missing functionality that I need for ATA and adds the specific
> ATA dma driver code.
>
> The biggest minus for the Freescale version is that it is really opaque.
> Its implementation makes it hard to figure out what the code is actually
> doing.
Yes, this makes it difficult to maintain and is what has kept the
Freescale Bestcomm code from being accepted into the kernel. I would
have preferred not to write an alternate version, but, at the time,
Motorola had a take-or-leave-it stance; they wouldn't consider accepting
patches to clean it up. So then I planned to simply fork their version,
but found the code so convoluted that it was easier to start from scratch.
> If there is a chance of getting the Freescale Bestcomm code into Sylvain's
> tree (and on up the line to Linus) I would welcome that since I would not
> have to port other Bestcomm dependent drivers to the version in Sylvain's
> tree. I would gladly port the current FEC code to the Freescale Bestcomm
> code to avoid the work of porting the other drivers. Also we at Freescale
> would prefer to have one version of the Bestcomm code circulating.
>
> So I guess my question for those with an opinion is what version of Bestcomm
> should be we use for 5200.
It would be better to have one version, and my bestcomm code could be
replaced in Linux by code derived from the current Freescale code. The
challenges are political. Neither Freescale nor the Linux community is
willing to relinquish control of their code to the other. Potentially,
this can be addressed by having a Freescaler, who is responsive to the
Linux community, be a Linux maintainer for the bestcomm code. There are
also licensing concerns though, since Freescale needs to also license
their code under non-GPL terms.
Until these challenges are resolved, I think we're stuck with two versions.
Thanks,
-Dale
^ permalink raw reply
* Re: [PATCH] powerpc: Extends HCALL interface for Infiniband usage
From: Michal Ostrowski @ 2006-03-30 19:13 UTC (permalink / raw)
To: linuxppc-dev
For the sake of discussion...
A generic hcall wrapper through which any hcall may be made; an
alternative to having to wwrite-out each possible combination of
numbers of input and output arguments.
Needs the obvious fix to meek Heiko's requirements (9-in, 9-out).
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
arch/powerpc/platforms/pseries/hvCall.S | 45 ++++++++++++++++++++++++++++++++
include/asm-powerpc/hvcall.h | 10 +++++++
2 files changed, 55 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/hvCall.S b/arch/powerpc/platforms/pseries/hvCall.S
index 176e8da..7bb29b5 100644
--- a/arch/powerpc/platforms/pseries/hvCall.S
+++ b/arch/powerpc/platforms/pseries/hvCall.S
@@ -129,3 +129,48 @@ _GLOBAL(plpar_hcall_4out)
mtcrf 0xff,r0
blr /* return r3 = status */
+
+/* long plpar_hcall_generic(unsigned long opcode, R3
+ unsigned long in_args[8], R4
+ unsigned long out_args[8]) R5
+*/
+_GLOBAL(plpar_hcall_generic)
+ mfcr r0
+ std r0,-8(r1)
+ stdu r1,-48(r1)
+
+ std r4,16(r1)
+ std r5,8(r1)
+
+ mr r12, r4 /* Load HCALL args into r4...r11. */
+ ld r4, 0(r12)
+ ld r5, 8(r12)
+ ld r6, 16(r12)
+ ld r7, 24(r12)
+ ld r8, 32(r12)
+ ld r9, 40(r12)
+ ld r10, 48(r12)
+ ld r11, 56(r12)
+
+ HVSC /* Invoke the hypervisor. */
+
+ ld r12, 8(r1) /* Check if return args need */
+ cmpi 0, r12, 0 /* to be saved. */
+ beq 1f
+
+ std r4, 0(r12)
+ std r5, 8(r12)
+ std r6, 16(r12)
+ std r7, 24(r12)
+ std r8, 32(r12)
+ std r9, 40(r12)
+ std r10, 48(r12)
+ std r11, 56(r12)
+1:
+ ld r1,0(r1)
+ ld r0,-8(r1)
+
+ mtcrf 0xff,r0
+ blr /* return r3 = status */
+
+
diff --git a/include/asm-powerpc/hvcall.h b/include/asm-powerpc/hvcall.h
index 38ca9ad..3bf6425 100644
--- a/include/asm-powerpc/hvcall.h
+++ b/include/asm-powerpc/hvcall.h
@@ -175,6 +175,16 @@ long plpar_hcall_4out(unsigned long opco
unsigned long *out3,
unsigned long *out4);
+/* plpar_hcall_generic()
+ *
+ * generic hcall pass-thru mechanism
+ *
+ */
+long plpar_hcall_generic(unsigned long opcode,
+ unsigned long in_args[8],
+ unsigned long out_args[8]);
+
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
^ permalink raw reply related
* Re: [PATCH 3/5] powerpc: Move create_(instruction|branch|function_call) into util.h
From: Linas Vepstas @ 2006-03-30 18:10 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060330061300.0B12567B6C@ozlabs.org>
Hi,
A minor quibble from the dept. of naming things:
On Thu, Mar 30, 2006 at 05:12:59PM +1100, Michael Ellerman wrote:
> ===================================================================
> --- /dev/null
> +++ to-merge/include/asm-powerpc/util.h
> @@ -0,0 +1,56 @@
> +
> +#ifndef _ASM_POWERPC_UTIL_H
> +#define _ASM_POWERPC_UTIL_H
> +
> +static inline void create_instruction(unsigned long addr, unsigned int instr)
Surely there is a more descriptive name for this new file than "util.h"?
How about "dynamic_insn.h" or "insn_patch.h" or "dyn_fixup.h" or
something like that?
--linas
^ permalink raw reply
* Subject: [PATCH] Add ATA bestcomm dma support for MPC5200B.
From: John Rigby @ 2006-03-30 17:51 UTC (permalink / raw)
To: Sylvain Munaut, Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 37281 bytes --]
[PATCH] Add ATA bestcomm dma support for MPC5200B.
This works on the Lite5200B platform with some caveats.
The board seems to have a layout issue so the ata signals have
a noise problem. You need to use an UDMA cable even though
the connector on the board does not allow most UDMA cables to
be plugged in. To get around this you can remove the key pin
on the board connector or poke a hole in the cable connector.
You also want to use the shortest cable you can get. I ended up
cutting the cable just past the slave connector.
Even with the above changes some drives will not work.
With the right cable and the right drive you can do UDMA1.
Signed-off-by: John Rigby <jrigby@freescale.com>
---
arch/ppc/syslib/bestcomm/Makefile | 1
arch/ppc/syslib/bestcomm/ata.c | 143 +++++++
arch/ppc/syslib/bestcomm/ata.h | 49 ++
arch/ppc/syslib/bestcomm/bestcomm.c | 4
arch/ppc/syslib/bestcomm/bestcomm.h | 27 +
arch/ppc/syslib/bestcomm/sdma_ata_task.c | 61 +++
arch/ppc/syslib/mpc52xx_setup.c | 7
drivers/ide/Kconfig | 11 +
drivers/ide/ppc/mpc52xx_ide.c | 640
+++++++++++++++++++++++++++++-
9 files changed, 915 insertions(+), 28 deletions(-)
create mode 100644 arch/ppc/syslib/bestcomm/ata.c
create mode 100644 arch/ppc/syslib/bestcomm/ata.h
create mode 100644 arch/ppc/syslib/bestcomm/sdma_ata_task.c
01a9cf3296c225320105d26201fe7e86596a2ad5
diff --git a/arch/ppc/syslib/bestcomm/Makefile
b/arch/ppc/syslib/bestcomm/Makefile
index 02cc99a..f04c5ad 100644
--- a/arch/ppc/syslib/bestcomm/Makefile
+++ b/arch/ppc/syslib/bestcomm/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_PPC_BESTCOMM) += bestcomm.o
obj-$(CONFIG_FEC_MPC52xx) += sdma_fec_rx_task.o sdma_fec_tx_task.o fec.o
+obj-$(CONFIG_BLK_DEV_MPC52xx_IDE_DMA) += sdma_ata_task.o ata.o
diff --git a/arch/ppc/syslib/bestcomm/ata.c b/arch/ppc/syslib/bestcomm/ata.c
new file mode 100644
index 0000000..6feae2e
--- /dev/null
+++ b/arch/ppc/syslib/bestcomm/ata.c
@@ -0,0 +1,143 @@
+/*
+ * arch/ppc/syslib/bestcomm/ata.c
+ *
+ * Driver for MPC52xx processor BestComm ATA controller
+ *
+ * Copyright (C) 2006 Freescale - John Rigby
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ * Patterned after:
+ * arch/ppc/syslib/bestcomm/fec.c
+ *
+ * Author: Dale Farnsworth <dfarnsworth@mvista.com>
+ * 2003-2004 (c) MontaVista, Software, Inc.
+ */
+
+#include <linux/config.h>
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <asm/errno.h>
+#include <asm/io.h>
+
+#include <asm/mpc52xx.h>
+
+#include "bestcomm.h"
+#include "ata.h"
+
+/*
+ * Initialize the shared ATA rx/tx task.
+ * Returns task number of ATA task.
+ * Returns -1 on failure
+ */
+int sdma_ata_init(struct sdma *s, int maxbufsize)
+{
+ static int tasknum = -1;
+ static struct sdma_bd2 *bd2 = 0;
+ static u32 bd_pa;
+
+ struct sdma_ata_var *var;
+
+ if (tasknum < 0) {
+ tasknum = sdma_load_task(sdma_ata_task);
+ if (tasknum < 0)
+ return tasknum;
+ }
+
+ if (!bd2)
+ bd2 = (struct sdma_bd2 *)sdma_sram_alloc(sizeof(*bd2) * s->num_bd,
+ SDMA_BD_ALIGN, &bd_pa);
+ if (!bd2)
+ return -ENOMEM;
+
+ sdma_disable_task(tasknum);
+
+ s->flags = SDMA_FLAGS_BD2;
+ s->tasknum = tasknum;
+ s->bd2 = bd2;
+ s->index = 0;
+ s->outdex = 0;
+ memset(bd2, 0, sizeof(*bd2) * s->num_bd);
+
+ var = (struct sdma_ata_var *)sdma_task_var(tasknum);
+ var->enable = sdma_io_pa(&sdma.io->tcr[tasknum]);
+ var->bd_base = bd_pa;
+ var->bd_last = bd_pa + (s->num_bd - 1)*sizeof(struct sdma_bd2);
+ var->bd_start = bd_pa;
+ var->buffer_size = maxbufsize;
+
+ printk("here in %s calling sdma_dump ata var is %08x\n", __FUNCTION__,
var);
+ sdma_dump();
+
+#if 0
+ /* some tasks may need this set but ata apparently isn't one of them */
+ sdma_set_size(tasknum, 4, 4) /* SrcSz, DstSz */
+#endif
+ sdma_set_task_pragma(tasknum, SDMA_ATA_PRAGMA);
+ sdma_set_task_auto_start(tasknum, tasknum);
+
+ /* clear pending interrupt bits */
+ out_be32(&sdma.io->IntPend, 1<<tasknum);
+
+ out_8(&sdma.io->ipr[SDMA_INITIATOR_ATA_RX], SDMA_IPR_ATA_RX);
+ out_8(&sdma.io->ipr[SDMA_INITIATOR_ATA_TX], SDMA_IPR_ATA_TX);
+
+ return tasknum;
+}
+
+
+/*
+ * Initialize ATA receive task.
+ */
+void sdma_ata_rx_init(struct sdma *s)
+{
+ struct sdma_ata_inc *inc;
+
+ inc = (struct sdma_ata_inc *)sdma_task_inc(s->tasknum);
+ inc->incr_bytes = -(s16)sizeof(u32);
+ inc->incr_src = 0;
+ inc->incr_dst = sizeof(u32);
+
+ sdma_set_initiator(s->tasknum, SDMA_INITIATOR_ATA_RX);
+}
+
+/*
+ * Initialize ATA transmit task.
+ */
+void sdma_ata_tx_init(struct sdma *s)
+{
+ struct sdma_ata_inc *inc;
+
+ inc = (struct sdma_ata_inc *)sdma_task_inc(s->tasknum);
+ inc->incr_bytes = -(s16)sizeof(u32);
+ inc->incr_src = sizeof(u32);
+ inc->incr_dst = 0;
+
+ sdma_set_initiator(s->tasknum, SDMA_INITIATOR_ATA_TX);
+}
+
+/*
+ * Reset all the ATA task's bds
+ */
+void sdma_ata_reset(struct sdma *s)
+{
+ struct sdma_ata_var *var;
+
+ sdma_reset_buffers2(s);
+ /*
+ * Always start at the beginning (the ATA task modifies bd_start on
writes)
+ */
+ s->outdex = s->index = 0;
+ var = (struct sdma_ata_var *)sdma_task_var(s->tasknum);
+ var->bd_start = var->bd_base;
+}
+
+EXPORT_SYMBOL(sdma_ata_init);
+EXPORT_SYMBOL(sdma_ata_rx_init);
+EXPORT_SYMBOL(sdma_ata_tx_init);
+EXPORT_SYMBOL(sdma_ata_reset);
diff --git a/arch/ppc/syslib/bestcomm/ata.h b/arch/ppc/syslib/bestcomm/ata.h
new file mode 100644
index 0000000..6f2e99d
--- /dev/null
+++ b/arch/ppc/syslib/bestcomm/ata.h
@@ -0,0 +1,49 @@
+/*
+ * arch/ppc/syslib/bestcomm/ata.h
+ *
+ * Driver for MPC52xx processor BestComm ATA controller
+ *
+ * Copyright (C) 2006 Freescale - John Rigby
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ * Patterned after:
+ * arch/ppc/syslib/bestcomm/fec.c
+ *
+ * Author: Dale Farnsworth <dfarnsworth@mvista.com>
+ * 2003-2004 (c) MontaVista, Software, Inc.
+ */
+
+#ifndef __BESTCOMM_ATA_H__
+#define __BESTCOMM_ATA_H__
+
+
+/* ata task vars that need to be set before enabling the task */
+struct sdma_ata_var {
+ u32 enable; /* (u16*) address of task's control register */
+ u32 bd_base; /* (struct sdma_bd*) beginning of ring buffer */
+ u32 bd_last; /* (struct sdma_bd*) end of ring buffer */
+ u32 bd_start; /* (struct sdma_bd*) current bd */
+ u32 buffer_size; /* size of receive buffer */
+};
+
+/* ata task incs that need to be set before enabling the task */
+struct sdma_ata_inc {
+ u16 pad0;
+ s16 incr_bytes;
+ u16 pad1;
+ s16 incr_dst;
+ u16 pad2;
+ s16 incr_src;
+};
+
+extern int sdma_ata_init(struct sdma *s, int maxbufsize);
+extern void sdma_ata_rx_init(struct sdma *s);
+extern void sdma_ata_tx_init(struct sdma *s);
+extern void sdma_ata_reset(struct sdma *s);
+
+extern u32 sdma_ata_task[];
+
+#endif /* __BESTCOMM_ATA_H__ */
diff --git a/arch/ppc/syslib/bestcomm/bestcomm.c
b/arch/ppc/syslib/bestcomm/bestcomm.c
index 76d5a9b..0f249d6 100644
--- a/arch/ppc/syslib/bestcomm/bestcomm.c
+++ b/arch/ppc/syslib/bestcomm/bestcomm.c
@@ -43,12 +43,12 @@ static spinlock_t sdma_lock = SPIN_LOCK_
void sdma_dump(void)
{
int i;
- printk("** SDMA registers: pa = %08x, va = %08x\n", sdma.base_reg_addr,
sdma.io);
+
+ printk("** SDMA registers: pa = %08x, va = %08x\n",
(u32)sdma.base_reg_addr, (u32)sdma.io);
printk("** taskBar = %08x\n", sdma.io->taskBar);
printk("** currentPointer = %08x\n", sdma.io->currentPointer);
printk("** endPointer = %08x\n", sdma.io->endPointer);
printk("** variablePointer = %08x\n", sdma.io->variablePointer);
-
printk("** IntVect1 = %08x\n", sdma.io->IntVect1);
printk("** IntVect2 = %08x\n", sdma.io->IntVect2);
printk("** PtdCntrl = %08x\n", sdma.io->PtdCntrl);
diff --git a/arch/ppc/syslib/bestcomm/bestcomm.h
b/arch/ppc/syslib/bestcomm/bestcomm.h
index 18cb58f..75ff7d2 100644
--- a/arch/ppc/syslib/bestcomm/bestcomm.h
+++ b/arch/ppc/syslib/bestcomm/bestcomm.h
@@ -237,7 +237,7 @@ static inline int sdma_desc_initiator(u3
static inline void sdma_set_desc_initiator(u32 *desc, int initiator)
{
*desc = (*desc & ~(0x1f << SDMA_DRD_INITIATOR_SHIFT)) |
- ((initiator << SDMA_DRD_INITIATOR_SHIFT) & 0x1f);
+ ((initiator & 0x1f) << SDMA_DRD_INITIATOR_SHIFT);
}
static inline void sdma_submit_buffer(struct sdma *s, void *cookie, void
*data,
@@ -284,12 +284,23 @@ static inline void *sdma_retrieve_buffer
return cookie;
}
+static inline void sdma_reset_buffers(struct sdma *s)
+{
+ while (!sdma_queue_empty(s)) {
+ s->bd[s->outdex].status = 0;
+ s->bd[s->outdex].data = 0;
+ sdma_retrieve_buffer(s, NULL);
+ }
+ s->index = s->outdex = 0;
+}
+
static inline void sdma_submit_buffer2(struct sdma *s, void *cookie,
void *data1, void *data2, int length)
{
#ifdef CONFIG_BESTCOMM_DEBUG
BUG_ON(!(s->flags & SDMA_FLAGS_BD2));
#endif
+
s->cookie[s->index] = cookie;
s->bd2[s->index].data1 = data1;
s->bd2[s->index].data2 = data2;
@@ -312,6 +323,17 @@ static inline void *sdma_retrieve_buffer
return cookie;
}
+static inline void sdma_reset_buffers2(struct sdma *s)
+{
+ while (!sdma_queue_empty(s)) {
+ s->bd2[s->outdex].status = 0;
+ s->bd2[s->outdex].data1 = 0;
+ s->bd2[s->outdex].data2 = 0;
+ sdma_retrieve_buffer2(s, NULL);
+ }
+ s->index = s->outdex = 0;
+}
+
#define SDMA_TASK_MAGIC 0x4243544B /* 'BCTK' */
/* the size fields are given in number of 32-bit words */
@@ -351,7 +373,7 @@ static inline int sdma_desc_is_drd(u32 d
(0 << SDMA_PRAGMA_BIT_RST_ERROR_NO) | \
(0 << SDMA_PRAGMA_BIT_PACK) | \
(0 << SDMA_PRAGMA_BIT_INTEGER) | \
- (1 << SDMA_PRAGMA_BIT_SPECREAD) | \
+ (0 << SDMA_PRAGMA_BIT_SPECREAD) | \
(1 << SDMA_PRAGMA_BIT_CW) | \
(1 << SDMA_PRAGMA_BIT_RL))
@@ -469,6 +491,7 @@ extern int sdma_load_task(u32 *task_imag
extern void *sdma_sram_alloc(int size, int alignment, u32 *dma_handle);
extern void sdma_init_bd(struct sdma *s);
extern void sdma_init_bd2(struct sdma *s);
+extern void sdma_set_initiator(int task, int initiator);
#define FIELD_OFFSET(s,f) ((unsigned long)(&(((struct s*)0)->f)))
diff --git a/arch/ppc/syslib/bestcomm/sdma_ata_task.c
b/arch/ppc/syslib/bestcomm/sdma_ata_task.c
new file mode 100644
index 0000000..5613545
--- /dev/null
+++ b/arch/ppc/syslib/bestcomm/sdma_ata_task.c
@@ -0,0 +1,61 @@
+/*
+ * sdma_ata_task.c
+ *
+ * Created based on bestcom/code_dma/image_rtos1/dma_image.hex
+ */
+
+#include <linux/types.h>
+
+/*
+ * The header consists of the following fields:
+ * uint32_t magic;
+ * uint8_t desc_size;
+ * uint8_t var_size;
+ * uint8_t inc_size;
+ * uint8_t first_var;
+ * uint8_t reserved[8];
+ *
+ * The size fields contain the number of 32-bit words.
+*/
+
+uint32_t sdma_ata_task[] = {
+ /* header */
+ 0x4243544b,
+ 0x0e060709,
+ 0x00000000,
+ 0x00000000,
+
+ /* Task descriptors */
+ 0x8198009b, /* LCD: idx0 = var3; idx0 <= var2; idx0 += inc3 */
+ 0x13e00c08, /* DRD1A: var3 = var1; FN=0 MORE init=31 WS=0 RS=0 */
+ 0xb8000264, /* LCD: idx1 = *idx0, idx2 = var0; idx1 < var9; idx1 +=
inc4, idx2 += inc4 */
+ 0x10000f00, /* DRD1A: var3 = idx0; FN=0 MORE init=0 WS=0 RS=0 */
+ 0x60140002, /* DRD2A: EU0=0 EU1=0 EU2=0 EU3=2 EXT init=0 WS=2 RS=2
*/
+ 0x0c8cfc8a, /* DRD2B1: *idx2 = EU3(); EU3(*idx2,var10) */
+ 0xd8988240, /* LCDEXT: idx1 = idx1; idx1 > var9; idx1 += inc0 */
+ 0xf845e011, /* LCDEXT: idx2 = *(idx0 + var00000015); ; idx2 += inc2
*/
+ 0xb845e00a, /* LCD: idx3 = *(idx0 + var00000019); ; idx3 += inc1 */
+ 0x0bfecf90, /* DRD1A: *idx3 = *idx2; FN=0 TFD init=31 WS=3 RS=3 */
+ 0x9898802d, /* LCD: idx1 = idx1; idx1 once var0; idx1 += inc5 */
+ 0x64000005, /* DRD2A: EU0=0 EU1=0 EU2=0 EU3=5 INT EXT init=0 WS=0
RS=0 */
+ 0x0c0cf849, /* DRD2B1: *idx0 = EU3(); EU3(idx1,var9) */
+ 0x000001f8, /* NOP */
+
+
+ /* VAR[9]-VAR[14] */
+ 0x40000000,
+ 0x7fff7fff,
+ 0x00000000,
+ 0x00000000,
+ 0x00000000,
+ 0x00000000,
+
+ /* INC[0]-INC[6] */
+ 0x40000000,
+ 0xe0000000,
+ 0xe0000000,
+ 0xa000000c,
+ 0x20000000,
+ 0x00000000,
+ 0x00000000,
+};
diff --git a/arch/ppc/syslib/mpc52xx_setup.c
b/arch/ppc/syslib/mpc52xx_setup.c
index 508b241..3c9cd42 100644
--- a/arch/ppc/syslib/mpc52xx_setup.c
+++ b/arch/ppc/syslib/mpc52xx_setup.c
@@ -220,7 +220,6 @@ mpc52xx_calibrate_decr(void)
tb_to_us = mulhwu_scale_factor(xlbfreq / divisor, 1000000);
}
-
void __init
mpc52xx_setup_cpu(void)
{
@@ -247,8 +246,9 @@ mpc52xx_setup_cpu(void)
out_be16(&cdm->fd_counters, 0x5555);
/* Configure the XLB Arbiter priorities */
- out_be32(&xlb->master_pri_enable, 0xff);
- out_be32(&xlb->master_priority, 0x11111111);
+ /* Give PPC and BestComm the same priority on the XLB */
+ out_be32(&xlb->master_pri_enable, 0xf);
+ out_be32(&xlb->master_priority, 0x00007131);
/* Enable ram snooping for 1GB window */
out_be32(&xlb->config, in_be32(&xlb->config) | MPC52xx_XLB_CFG_SNOOP);
@@ -265,7 +265,6 @@ unmap_regs:
if (xlb) iounmap(xlb);
}
-
int mpc52xx_match_psc_function(int psc_idx, const char *func)
{
struct mpc52xx_psc_func *cf = mpc52xx_psc_functions;
diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig
index e391cee..6ecaee7 100644
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -973,6 +973,17 @@ config BLK_DEV_MPC52xx_IDE
tristate "MPC52xx Builtin IDE support"
depends on PPC_MPC52xx && IDE=y
+config BLK_DEV_MPC52xx_IDE_MDMA
+ bool "MDMA support"
+ depends on BLK_DEV_MPC52xx_IDE
+
+config BLK_DEV_MPC52xx_IDE_UDMA
+ bool "UDMA support"
+ depends on BLK_DEV_MPC52xx_IDE
+
+config BLK_DEV_MPC52xx_IDE_DMA
+ def_bool BLK_DEV_MPC52xx_IDE_UDMA || BLK_DEV_MPC52xx_IDE_MDMA
+
# no isa -> no vlb
config IDE_CHIPSETS
bool "Other IDE chipset support"
diff --git a/drivers/ide/ppc/mpc52xx_ide.c b/drivers/ide/ppc/mpc52xx_ide.c
index 5970f7b..7ab1bcc 100644
--- a/drivers/ide/ppc/mpc52xx_ide.c
+++ b/drivers/ide/ppc/mpc52xx_ide.c
@@ -5,6 +5,7 @@
*
*
* Copyright (C) 2006 Sylvain Munaut <tnt@246tNt.com>
+ * Copyright (C) 2005,2006 Freescale - Bernard Kuhn, John Rigby
* Copyright (C) 2003 Mipsys - Benjamin Herrenschmidt
*
* This file is licensed under the terms of the GNU General Public License
@@ -24,8 +25,28 @@
#include <asm/io.h>
#include <asm/ppcboot.h>
+#include <syslib/bestcomm/bestcomm.h>
+#include <syslib/bestcomm/ata.h>
+
#include "mpc52xx_ide.h"
+#define CONFIG_BLK_DEV_IDE_MPC52xx_LIMIT_TO_UDMA1
+#define CONFIG_BLK_DEV_IDE_MPC52xx_SHOWDETAILS 1
+
+#define MAX_DMA_BUFFERS 128
+#define MAX_DMA_BUFFER_SIZE 0x20000
+
+#undef DEBUG
+#define DEBUG
+
+#undef DPRINTK
+#ifdef DEBUG
+#define DPRINTK(fmt, args...) printk(fmt, ## args)
+#else
+#define DPRINTK(fmt, args...)
+#endif
+
+typedef unsigned long ide_ioreg_t;
/* Private structures used by the driver */
@@ -42,11 +63,6 @@ struct mpc52xx_ata_timings {
int using_udma;
};
-struct mpc52xx_ide_priv {
- unsigned int ipb_period; /* in ps */
- struct mpc52xx_ata __iomem *ata_regs;
- struct mpc52xx_ata_timings timings[2];
-};
/* ATAPI-4 PIO specs (arranged for the 5200, cfr User Manual) */
/* numbers in ns, extrapolation done by code */
@@ -58,9 +74,166 @@ static int ataspec_t2i[5] = { 0, 0,
static int ataspec_t4[5] = { 30, 20, 15, 10, 10};
static int ataspec_ta[5] = { 35, 35, 35, 35, 35};
-/* Helpers to compute timing parameters */
+/* Helper to compute timing parameters */
#define CALC_CLK_VALUE_UP(c,v) (((v) + c - 1) / c)
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_DMA
+
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_MDMA
+
+/* ATAPI-4 MDMA specs (in clocks) */
+struct mdmaspec {
+ u32 t0M[3];
+ u32 td[3];
+ u32 th[3];
+ u32 tj[3];
+ u32 tkw[3];
+ u32 tm[3];
+ u32 tn[3];
+};
+
+static struct mdmaspec mdmaspec66 = {
+ {32, 10, 8},
+ {15, 6, 5},
+ {2, 1, 1},
+ {2, 1, 1},
+ {15, 4, 2},
+ {4, 2, 2},
+ {1, 1, 1}
+};
+
+static struct mdmaspec mdmaspec132 = {
+ {64, 20, 16},
+ {29, 11, 10},
+ {3, 2, 2},
+ {3, 1, 1},
+ {29, 7, 4},
+ {7, 4, 4},
+ {2, 1, 1}
+};
+
+#endif
+
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_UDMA
+
+/* ATAPI-4 UDMA specs (in clocks) */
+struct udmaspec {
+ u32 tcyc[6];
+ u32 t2cyc[6];
+ u32 tds[6];
+ u32 tdh[6];
+ u32 tdvs[6];
+ u32 tdvh[6];
+ u32 tfs_min[6];
+ u32 tli_max[6];
+ u32 tmli[6];
+ u32 taz[6];
+ u32 tzah[6];
+ u32 tenv_min[6];
+ u32 tsr[6];
+ u32 trfs[6];
+ u32 trp[6];
+ u32 tack[6];
+ u32 tss[6];
+};
+
+struct udmaspec udmaspec66 = {
+ {8, 5, 4, 3, 2, 2},
+ {16, 11, 8, 6, 4 , 2},
+ {1, 1, 1, 1, 1, 1},
+ {1, 1, 1, 1, 1, 1},
+ {5, 4, 3, 2, 1, 1},
+ {1, 1, 1, 1, 1, 1},
+ {16, 14, 12, 9, 8, 6},
+ {10, 10, 10, 7, 8, 5},
+ {2, 2, 2, 2, 2, 2},
+ {1, 1, 1, 1, 1, 1},
+ {2, 2, 2, 2, 2, 2},
+ {2, 2, 2, 2, 2, 2},
+ {3, 2, 2, 2, 2, 2},
+ {5, 5, 4, 4, 4, 4},
+ {11, 9, 7, 7, 7, 6},
+ {2, 2, 2, 2, 2, 2},
+ {4, 4, 4, 4, 4, 4}
+};
+
+struct udmaspec udmaspec132 = {
+ {15, 10, 6, 7, 2, 3},
+ {31, 21, 12, 12, 5, 6},
+ {2, 2, 1, 1, 0, 1},
+ {1, 1, 1, 1, 0, 1},
+ {10, 7, 5, 3, 1, 1},
+ {1, 1, 1, 1, 1, 1},
+ {30, 27, 23, 15, 16, 12},
+ {20, 20, 20, 13, 14, 10},
+ {3, 3, 3, 3, 2, 3},
+ {2, 2, 2, 2, 1, 2},
+ {3, 3, 3, 3, 2, 3},
+ {3, 3, 3, 3, 2, 3},
+ {7, 4, 3, 3, 2, 3},
+ {10, 10, 8, 8, 7, 7},
+ {22, 17, 14, 14, 13, 12},
+ {3, 3, 3, 3, 2, 3},
+ {7, 7, 7, 7, 6, 7},
+};
+
+
+#endif
+
+#endif /* CONFIG_BLK_DEV_MPC52xx_IDE_DMA */
+
+struct mpc52xx_ide_priv {
+ unsigned int ipb_period; /* in ps */
+ struct mpc52xx_ata __iomem *ata_regs;
+ struct mpc52xx_ata_timings timings[2];
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_DMA
+ struct sdma *sdma;
+ struct udmaspec *udmaspec;
+ struct mdmaspec *mdmaspec;
+ int mpc52xx_ata_dma_last_write;
+#endif
+};
+
+static u8
+mpc52xx_dma2pio (u8 xfer_rate)
+{
+ switch(xfer_rate) {
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_DMA
+ case XFER_UDMA_6:
+ case XFER_UDMA_5:
+ case XFER_UDMA_4:
+ case XFER_UDMA_3:
+ case XFER_UDMA_2:
+ case XFER_UDMA_1:
+ case XFER_UDMA_0:
+ case XFER_MW_DMA_2:
+ case XFER_PIO_4:
+ //return 3;
+ return 4;
+ case XFER_MW_DMA_1:
+ case XFER_PIO_3:
+ return 3;
+ case XFER_SW_DMA_2:
+ case XFER_PIO_2:
+ return 2;
+ case XFER_MW_DMA_0:
+ case XFER_SW_DMA_1:
+ case XFER_SW_DMA_0:
+#else
+ case XFER_PIO_4:
+ return 4;
+ case XFER_PIO_3:
+ return 3;
+ case XFER_PIO_2:
+ return 2;
+#endif /* CONFIG_BLK_DEV_MPC52xx_IDE_DMA */
+ case XFER_PIO_1:
+ case XFER_PIO_0:
+ case XFER_PIO_SLOW:
+ default:
+ return 0;
+ }
+}
/* ========================================================================
*/
/* IDE Driver & Aux functions
*/
@@ -100,6 +273,99 @@ mpc52xx_ide_compute_pio_timing(
timing->pio2 = (t4 << 24) | (t1 << 16) | (ta << 8);
}
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_DMA
+
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_UDMA
+
+static void mpc52xx_ide_calc_udma_timings(ide_drive_t *drive, u8 speed)
+{
+ struct mpc52xx_ide_priv *priv = drive->hwif->hwif_data;
+
+ int which = drive->select.b.unit & 0x01;
+ u32 t2cyc, tcyc, tds, tdh, tdvs, tdvh, tfs, tli, tmli, taz, tenv, tsr,
tss, trfs, trp, tack, tzah;
+
+ t2cyc = priv->udmaspec->t2cyc[speed];
+ tcyc = priv->udmaspec->tcyc[speed];
+ tds = priv->udmaspec->tds[speed];
+ tdh = priv->udmaspec->tdh[speed];
+ tdvs = priv->udmaspec->tdvs[speed];
+ tdvh = priv->udmaspec->tdvh[speed];
+ tfs = priv->udmaspec->tfs_min[speed];
+ tmli = priv->udmaspec->tmli[speed];
+ tenv = priv->udmaspec->tenv_min[speed];
+ tss = priv->udmaspec->tss[speed];
+ trp = priv->udmaspec->trp[speed];
+ tack = priv->udmaspec->tack[speed];
+ tzah = priv->udmaspec->tzah[speed];
+ taz = priv->udmaspec->taz[speed];
+ trfs = priv->udmaspec->trfs[speed];
+ tsr = priv->udmaspec->tsr[speed];
+ tli = priv->udmaspec->tli_max[speed];
+
+ DPRINTK ("UDMA t2cyc = %d\n", t2cyc);
+ DPRINTK ("UDMA tcyc = %d\n", tcyc);
+ DPRINTK ("UDMA tds = %d\n", tds);
+ DPRINTK ("UDMA tdh = %d\n", tdh);
+ DPRINTK ("UDMA tdvs = %d\n", tdvs);
+ DPRINTK ("UDMA tdvh = %d\n", tdvh);
+ DPRINTK ("UDMA tfs = %d\n", tfs);
+ DPRINTK ("UDMA tli = %d\n", tli);
+ DPRINTK ("UDMA tmli = %d\n", tmli);
+ DPRINTK ("UDMA taz = %d\n", taz);
+ DPRINTK ("UDMA tenv = %d\n", tenv);
+ DPRINTK ("UDMA tsr = %d\n", tsr);
+ DPRINTK ("UDMA tss = %d\n", tss);
+ DPRINTK ("UDMA trfs = %d\n", trfs);
+ DPRINTK ("UDMA trp = %d\n", trp);
+ DPRINTK ("UDMA tack = %d\n", tack);
+ DPRINTK ("UDMA tzah = %d\n", tzah);
+
+ priv->timings[which].udma1 = (t2cyc << 24) | (tcyc << 16) | (tds << 8)
| (tdh);
+ priv->timings[which].udma2 = (tdvs << 24) | (tdvh << 16) | (tfs << 8) |
(tli);
+ priv->timings[which].udma3 = (tmli << 24) | (taz << 16) | (tenv << 8) |
(tsr);
+ priv->timings[which].udma4 = (tss << 24) | (trfs << 16) | (trp << 8) |
(tack);
+ priv->timings[which].udma5 = (tzah << 24);
+
+ priv->timings[which].using_udma = 1;
+}
+
+#endif
+
+
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_UDMA
+
+static void mpc52xx_ide_calc_mdma_timings(ide_drive_t *drive, u8 speed)
+{
+ struct mpc52xx_ide_priv *priv = drive->hwif->hwif_data;
+ int which = drive->select.b.unit & 0x01;
+ u32 t0M, td, tkw, tm, th, tj, tn;
+
+ t0M = priv->mdmaspec->t0M[speed];
+ td = priv->mdmaspec->td[speed];
+ tkw = priv->mdmaspec->tkw[speed];
+ tm = priv->mdmaspec->tm[speed];
+ th = priv->mdmaspec->th[speed];
+ tj = priv->mdmaspec->tj[speed];
+ tn = priv->mdmaspec->tn[speed];
+
+ DPRINTK ("t0M = %d\n", t0M);
+ DPRINTK ("td = %d\n", td);
+ DPRINTK ("tkw = %d\n", tkw);
+ DPRINTK ("tm = %d\n", tm);
+ DPRINTK ("th = %d\n", th);
+ DPRINTK ("tj = %d\n", tj);
+ DPRINTK ("tn = %d\n", tn);
+
+ priv->timings[which].mdma1 = (t0M << 24) | (td << 16) | (tkw << 8) |
(tm);
+ priv->timings[which].mdma2 = (th << 24) | (tj << 16) | (tn << 8);
+
+ priv->timings[which].using_udma = 0;
+}
+
+#endif
+
+#endif /* CONFIG_BLK_DEV_MPC52xx_IDE_DMA */
+
static void
mpc52xx_ide_tuneproc(ide_drive_t *drive, u8 pio)
@@ -117,25 +383,51 @@ mpc52xx_ide_tuneproc(ide_drive_t *drive,
if (drive->select.all == HWIF(drive)->INB(IDE_SELECT_REG))
mpc52xx_ide_apply_timing(regs, &priv->timings[w]);
- /* Should we do it here or only in speedproc ? */
- ide_config_drive_speed(drive, pio + XFER_PIO_0);
+ /* Only call ide_config_drive_speed in speedproc */
}
static int
mpc52xx_ide_speedproc(ide_drive_t *drive, u8 speed)
{
- /* Configure PIO Mode */
- if (speed >= XFER_PIO_0 && speed <= XFER_PIO_4) {
- mpc52xx_ide_tuneproc(drive, speed - XFER_PIO_0);
- return 0;
- }
-
- /* DMA settings currently unsupported */
- printk(KERN_ERR
- "mpc52xx-ide: speedproc called with unsupported mode %d\n",
- speed);
+#ifdef CONFIG_BLK_DEV_IDE_MPC52xx_LIMIT_TO_UDMA1
+ if (speed > XFER_UDMA_1)
+ speed = XFER_UDMA_1;
+#else
+ if (speed > XFER_UDMA_4)
+ speed = XFER_UDMA_4;
+#endif
- return 1;
+ switch(speed) {
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_DMA
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_UDMA
+ case XFER_UDMA_4:
+ case XFER_UDMA_3:
+ case XFER_UDMA_2:
+ case XFER_UDMA_1:
+ case XFER_UDMA_0:
+ printk("%s: Setting UDMA %d timings\n", drive->name, speed -
XFER_UDMA_0);
+ mpc52xx_ide_calc_udma_timings(drive, speed - XFER_UDMA_0);
+ break;
+#endif
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_MDMA
+ case XFER_MW_DMA_2:
+ case XFER_MW_DMA_1:
+ case XFER_MW_DMA_0:
+ printk("%s: Setting MDMA %d timings\n", drive->name, speed -
XFER_MW_DMA_0);
+ mpc52xx_ide_calc_mdma_timings(drive, speed - XFER_MW_DMA_0);
+ break;
+#endif
+#endif /* CONFIG_BLK_DEV_MPC52xx_IDE_DMA */
+ case XFER_PIO_4:
+ case XFER_PIO_3:
+ case XFER_PIO_2:
+ case XFER_PIO_0:
+ break;
+ default:
+ return -EINVAL;
+ }
+ mpc52xx_ide_tuneproc(drive, mpc52xx_dma2pio(speed));
+ return ide_config_drive_speed(drive, speed);
}
static void
@@ -151,6 +443,225 @@ mpc52xx_ide_selectproc(ide_drive_t *driv
}
+
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_DMA
+
+static int mpc52xx_ide_dma_check(ide_drive_t *drive)
+{
+ u8 speed = ide_dma_speed(drive, 2);
+
+ DPRINTK("dma_check: speed=%x\n", speed);
+ if (speed == 0)
+ return -1;
+ mpc52xx_ide_speedproc(drive, speed);
+
+ if (ide_dma_enable(drive))
+ drive->using_dma = 1;
+ else
+ drive->using_dma = 0;
+
+ return 0;
+}
+
+static int mpc52xx_ide_build_dmatable(ide_drive_t *drive, struct request
*rq)
+{
+ struct mpc52xx_ide_priv *priv = drive->hwif->hwif_data;
+ struct mpc52xx_ata __iomem *regs = priv->ata_regs;
+ struct scatterlist *sg;
+ ide_hwif_t *hwif = HWIF(drive);
+ int i, count = 0;
+
+ /* Build sglist */
+ hwif->sg_nents = i = ide_build_sglist(drive, rq);
+ if (!hwif->sg_nents)
+ return 0;
+
+ if (hwif->sg_dma_direction == PCI_DMA_FROMDEVICE) {
+ sdma_ata_rx_init(priv->sdma);
+ } else {
+ sdma_ata_tx_init(priv->sdma);
+ }
+
+
+ sg = hwif->sg_table;
+ while (i && sg_dma_len(sg)) {
+ u32 cur_addr;
+ u32 cur_len;
+
+ cur_addr = sg_dma_address(sg);
+ cur_len = sg_dma_len(sg);
+
+ while (cur_len) {
+ unsigned int tc = (cur_len <= MAX_DMA_BUFFER_SIZE) ? cur_len:
MAX_DMA_BUFFER_SIZE;
+
+ if (hwif->sg_dma_direction == PCI_DMA_FROMDEVICE) {
+ invalidate_dcache_range((u32)phys_to_virt(cur_addr),
(u32)phys_to_virt(cur_addr)+(u32)tc);
+ sdma_submit_buffer2(priv->sdma, phys_to_virt(cur_addr),
(void *)®s->fifo_data, (void *)cur_addr, tc);
+ } else {
+ flush_dcache_range((u32)phys_to_virt(cur_addr),
(u32)phys_to_virt(cur_addr)+(u32)tc);
+ sdma_submit_buffer2(priv->sdma, phys_to_virt(cur_addr),
(void *)cur_addr, (void *)®s->fifo_data, tc);
+ }
+
+ //DPRINTK("SDMA setup @%08x, l: %x, nextbd: %d !\n", cur_addr,
tc, next_bd);
+ cur_addr += tc;
+ cur_len -= tc;
+ count++;
+ if(count == MAX_DMA_BUFFERS) {
+ printk(KERN_WARNING "%s: DMA table too
small\n",drive->name);
+ goto use_pio_instead;
+ };
+ }
+ sg++;
+ i--;
+ }
+
+ return 1;
+
+use_pio_instead:
+ sdma_ata_reset(priv->sdma);
+
+ pci_unmap_sg(hwif->pci_dev,
+ hwif->sg_table,
+ hwif->sg_nents,
+ hwif->sg_dma_direction);
+
+ return 0; /* revert to PIO for this request */
+}
+
+
+/* Teardown mappings after DMA has completed. */
+static void mpc52xx_ide_destroy_dmatable (ide_drive_t *drive)
+{
+ ide_hwif_t *hwif = drive->hwif;
+ struct pci_dev *dev = HWIF(drive)->pci_dev;
+ struct scatterlist *sg = hwif->sg_table;
+ int nents = hwif->sg_nents;
+
+ if (nents) {
+ pci_unmap_sg(dev, sg, nents, hwif->sg_dma_direction);
+ hwif->sg_nents = 0;
+ }
+}
+
+
+static void mpc52xx_ide_dma_exec_cmd(ide_drive_t *drive, u8 command)
+{
+ struct mpc52xx_ide_priv *priv = drive->hwif->hwif_data;
+ struct mpc52xx_ata __iomem *regs = priv->ata_regs;
+
+ mpc52xx_ide_wait_tip_bit_clear(regs);
+
+ /* issue cmd to drive */
+ ide_execute_command(drive, command, &ide_dma_intr, 2*WAIT_CMD, NULL);
+}
+
+
+static int mpc52xx_ide_dma_setup(ide_drive_t *drive)
+{
+ struct mpc52xx_ide_priv *priv = drive->hwif->hwif_data;
+ struct mpc52xx_ata __iomem *regs = priv->ata_regs;
+ ide_hwif_t *hwif = HWIF(drive);
+ struct request *rq = HWGROUP(drive)->rq;
+ int which = drive->select.b.unit & 0x01;
+ u8 dma_mode;
+
+ if (!mpc52xx_ide_build_dmatable(drive, rq)) {
+ ide_map_sg(drive, rq);
+ return 1;
+ };
+
+ if(hwif->sg_dma_direction == PCI_DMA_FROMDEVICE) { /* read */
+
+ dma_mode = MPC52xx_ATA_DMAMODE_IE | MPC52xx_ATA_DMAMODE_READ |
MPC52xx_ATA_DMAMODE_FE;
+
+ /* Setup FIFO if direction changed */
+ if (priv->mpc52xx_ata_dma_last_write) {
+ priv->mpc52xx_ata_dma_last_write = 0;
+ mpc52xx_ide_wait_tip_bit_clear(regs);
+ out_8(®s->dma_mode, MPC52xx_ATA_DMAMODE_FR);
+ /* Configure it with granularity to 7 like sample code */
+ out_8(®s->fifo_control, 7);
+ out_be16(®s->fifo_alarm, 128);
+ }
+ }
+ else {
+
+ dma_mode = MPC52xx_ATA_DMAMODE_IE | MPC52xx_ATA_DMAMODE_WRITE;
+
+ /* Setup FIFO if direction changed */
+ if (!priv->mpc52xx_ata_dma_last_write) {
+ priv->mpc52xx_ata_dma_last_write = 1;
+ mpc52xx_ide_wait_tip_bit_clear(regs);
+ /* Configure FIFO with granularity to 4 like sample code */
+ out_8(®s->fifo_control, 4);
+ //out_be16(®s->fifo_alarm, 256);
+ out_be16(®s->fifo_alarm, 128);
+ }
+ };
+
+ if (priv->timings[which].using_udma)
+ dma_mode |= MPC52xx_ATA_DMAMODE_UDMA;
+
+ mpc52xx_ide_wait_tip_bit_clear(regs);
+ out_8(®s->dma_mode, dma_mode);
+
+ drive->waiting_for_dma = 1;
+
+ return 0;
+};
+
+static void mpc52xx_ide_dma_start(ide_drive_t *drive)
+{
+ struct mpc52xx_ide_priv *priv = drive->hwif->hwif_data;
+ extern void xlb_clear(void);
+
+ xlb_clear();
+ sdma_set_task_auto_start(priv->sdma->tasknum, priv->sdma->tasknum);
+ sdma_enable(priv->sdma);
+}
+
+
+static int mpc52xx_ide_dma_end(ide_drive_t *drive)
+{
+ struct mpc52xx_ide_priv *priv = drive->hwif->hwif_data;
+
+ drive->waiting_for_dma = 0;
+
+ sdma_disable(priv->sdma);
+ sdma_clear_irq(priv->sdma);
+ sdma_ata_reset(priv->sdma);
+ mpc52xx_ide_destroy_dmatable(drive);
+
+ return 0;
+}
+
+
+static int mpc52xx_ide_dma_test_irq(ide_drive_t *drive)
+{
+ return (drive->waiting_for_dma);
+}
+
+
+static int mpc52xx_ide_dma_host_off(ide_drive_t *drive)
+{
+ return 0;
+}
+
+
+static int mpc52xx_ide_dma_host_on(ide_drive_t *drive)
+{
+ return 0;
+}
+
+static int mpc52xx_ide_dma_lostirq(ide_drive_t *drive)
+{
+ printk(KERN_ERR "%s: lost interrupt\n", drive->name);
+ return 0;
+}
+
+#endif /* CONFIG_BLK_DEV_MPC52xx_IDE_DMA */
+
+
static int
mpc52xx_ide_setup(
struct mpc52xx_ata __iomem *regs, struct mpc52xx_ide_priv *priv)
@@ -181,6 +692,21 @@ mpc52xx_ide_setup(
tslot = CALC_CLK_VALUE_UP(priv->ipb_period, 1000000);
out_be32(®s->share_cnt, tslot << 16);
+#ifdef CONFIG_BLK_DEV_IDE_MPC52xx_SHOWDETAILS
+ printk("ipb=%dMHz, set clock period to %d
ps\n",(int)(bd->bi_ipbfreq/1000000),
+ priv->ipb_period);
+#endif
+
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_DMA
+ if(bd->bi_ipbfreq/1000000 == 66) {
+ priv->mdmaspec = &mdmaspec66;
+ priv->udmaspec = &udmaspec66;
+ } else {
+ priv->mdmaspec = &mdmaspec132;
+ priv->udmaspec = &udmaspec132;
+ }
+#endif
+
/* Init imings to PIO0 (safest) */
memset(priv->timings, 0x00, 2*sizeof(struct mpc52xx_ata_timings));
@@ -189,9 +715,35 @@ mpc52xx_ide_setup(
mpc52xx_ide_apply_timing(regs, &priv->timings[0]);
+#ifdef CONFIG_BLK_DEV_IDE_MPC52xx_SHOWDETAILS
+ printk("GPIO config: %08x\n", in_be32((u32 *)0xf0000b00));
+ printk("ATA invalid: %08x\n", in_be32((u32 *)0xf0003a2c));
+ printk("ATA hostcnf: %08x\n", in_be32((u32 *)0xf0003a00));
+ printk("ATA pio1 : %08x\n", in_be32((u32 *)0xf0003a08));
+ printk("ATA pio2 : %08x\n", in_be32((u32 *)0xf0003a0c));
+ printk("XLB Arb cnf: %08x\n", in_be32((u32 *)0xf0001f40));
+#endif
+
return 0;
}
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_DMA
+static int
+mpc52xx_ata_sdma_setup(struct mpc52xx_ide_priv *priv)
+{
+ int rv = 0;
+
+ priv->sdma = sdma_alloc(MAX_DMA_BUFFERS);
+ if (!priv->sdma) {
+ return -ENOMEM;
+ }
+
+ (void) sdma_ata_init(priv->sdma, MAX_DMA_BUFFER_SIZE);
+
+ return rv;
+}
+#endif
+
static void
mpc52xx_ide_setup_hwif_ports(hw_regs_t *hw, struct mpc52xx_ata __iomem
*regs)
{
@@ -218,7 +770,7 @@ mpc52xx_ide_probe(struct platform_device
{
/* Vars */
ide_hwif_t *hwif;
- struct mpc52xx_ide_priv *priv;
+ struct mpc52xx_ide_priv *priv = NULL;
struct mpc52xx_gpio __iomem *gpio_regs = NULL;
struct mpc52xx_ata __iomem *ata_regs = NULL;
int ata_irq;
@@ -284,6 +836,7 @@ mpc52xx_ide_probe(struct platform_device
goto error;
}
+ memset(priv, 0, sizeof *priv);
priv->ata_regs = ata_regs;
/* Setup the ATA controller */
@@ -292,6 +845,13 @@ mpc52xx_ide_probe(struct platform_device
printk(KERN_ERR "mpc52xx-ide: Controller setup failed !\n");
goto error;
}
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_DMA
+ rv = mpc52xx_ata_sdma_setup(priv);
+ if (rv) {
+ printk(KERN_ERR "mpc52xx-ide: SDMA setup failed !\n");
+ goto error;
+ }
+#endif
/* Setup the hwif structure */
hwif->irq = ata_irq;
@@ -325,6 +885,38 @@ mpc52xx_ide_probe(struct platform_device
hwif->drives[1].autodma = hwif->autodma;
hwif->drives[1].no_io_32bit = 1; /* Anyone tried ? */
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_DMA
+
+ hwif->atapi_dma = 1;
+ hwif->autodma = 1;
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_MDMA
+ hwif->mwdma_mask = 0x07;
+#endif
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_UDMA
+ hwif->ultra_mask = 0x1F;
+#endif
+ hwif->ide_dma_off_quietly = &__ide_dma_off_quietly;
+ hwif->ide_dma_on = &__ide_dma_on;
+ hwif->ide_dma_check = &mpc52xx_ide_dma_check;
+ hwif->dma_setup = &mpc52xx_ide_dma_setup;
+ hwif->dma_exec_cmd = &mpc52xx_ide_dma_exec_cmd;
+ hwif->dma_start = &mpc52xx_ide_dma_start;
+ hwif->ide_dma_end = &mpc52xx_ide_dma_end;
+ hwif->ide_dma_test_irq = &mpc52xx_ide_dma_test_irq;
+ hwif->ide_dma_host_off = &mpc52xx_ide_dma_host_off;
+ hwif->ide_dma_host_on = &mpc52xx_ide_dma_host_on;
+ hwif->ide_dma_timeout = &__ide_dma_timeout;
+ hwif->ide_dma_lostirq = &mpc52xx_ide_dma_lostirq;
+
+#ifndef CONFIG_BLK_DEV_IDE_MPC52xx_LIMIT_TO_UDMA1
+ hwif->udma_four = 1;
+#endif
+ hwif->hwif_data = priv;
+
+ priv->mpc52xx_ata_dma_last_write = 1;
+
+#endif /* CONFIG_BLK_DEV_MPC52xx_IDE_DMA */
+
hwif->hwif_data = priv;
platform_set_drvdata(dev, hwif);
@@ -346,6 +938,14 @@ error:
release_mem_region(res_mem->start, sizeof(struct mpc52xx_ata));
+ if (priv) {
+#ifdef CONFIG_BLK_DEV_MPC52xx_IDE_DMA
+ if (priv->sdma) sdma_free(priv->sdma);
+#endif
+ kfree(priv);
+ }
+
+
return rv;
}
--
1.1.3
[-- Attachment #2: Type: text/html, Size: 59041 bytes --]
^ permalink raw reply related
* Re: Kernel for MPC Lite 5200 will not compile
From: John Rigby @ 2006-03-30 16:39 UTC (permalink / raw)
To: Linuxppc-embedded
In-Reply-To: <4b73d43f0603300829q7d45a029qdb5d8006ccda7275@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3788 bytes --]
After thinking about this more....I don't want to push getting the official
Freescale code into the tree. If Dale's code works as well as the Freescale
code then lets stay with it because it is a lot cleaner. The effort of
porting other drivers will hopefully be easier now that I have the
experience of having done ATA.
On 3/30/06, John Rigby <jcrigby@gmail.com> wrote:
>
> Sent this to Wolfgang last night. Accidently omitted Syvain and the list.
>
>
> The actual bestcomm "microcode" in Sylvain's tree is the same as the
> latest Freescale supported code. The linux driver code that interfaces with
> it is code written by Dale Farnsworth and has Montavista copyright. I don't
> know if it is based on old Freescale (Motorola) code or if it is Dale's
> creation (perhaps Dale can comment).
>
> I have just spent some time getting UDMA support into the ATA driver using
> the the bestcomm code in Sylvain's tree. In the process I found some bugs
> in the code that may explain some problems people have seen with the FEC
> driver. I'll try to get the patch out tomorrow.
>
> The ATA driver is a port from a version that worked on an older kernel and
> used the supported Freescale Bestcomm code. I did the port because it was
> my understanding that attempts to get the supported Freescale code into a
> public tree had met with resistance in the past. (Second hand info, I'm
> actually fairly new to the 52xx world).
>
> The pluses for the Freescale version is that several devices are supported
> that are not in Sylvain's tree. The version in Sylvain's kernel has a
> generic api plus specific code for FEC. My upcoming patch fixes some bugs,
> adds some missing functionality that I need for ATA and adds the specific
> ATA dma driver code.
>
> The biggest minus for the Freescale version is that it is really opaque.
> Its implementation makes it hard to figure out what the code is actually
> doing.
>
> If there is a chance of getting the Freescale Bestcomm code into Sylvain's
> tree (and on up the line to Linus) I would welcome that since I would not
> have to port other Bestcomm dependent drivers to the version in Sylvain's
> tree. I would gladly port the current FEC code to the Freescale Bestcomm
> code to avoid the work of porting the other drivers. Also we at Freescale
> would prefer to have one version of the Bestcomm code circulating.
>
> So I guess my question for those with an opinion is what version of
> Bestcomm should be we use for 5200.
>
> Thanks for your input
> John
>
> On 3/29/06, Wolfgang Denk <wd@denx.de> wrote:
>
> > In message < 442B11E8.7020107@246tNt.com> you wrote:
> > >
> > > It is ?
> >
> > I think so.
> >
> > > I don't know about the 2.6-denx, but the stock 2.6.15 should work just
> > fine.
> > > What's wrong with it ? (except it misses some drivers ... it should
> > compile
> > > and boot just fine)
> >
> > Isn't the current reengineered implementation of the BestComm code
> > based on an very old Freescale version, which has known limitations
> > and problems?
> >
> > Or has there any action resulted out of the discussion with the
> > Freescale engineers, and I have missed it?
> >
> > Best regards,
> >
> > Wolfgang Denk
> >
> > --
> > Software Engineering: Embedded and Realtime Systems, Embedded Linux
> > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> > In accord with UNIX philosophy, Perl gives you enough rope to hang
> > yourself. - L. Wall & R. L. Schwartz, _Programming Perl_
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
>
[-- Attachment #2: Type: text/html, Size: 5427 bytes --]
^ permalink raw reply
* Re: Kernel for MPC Lite 5200 will not compile
From: John Rigby @ 2006-03-30 16:29 UTC (permalink / raw)
To: Linuxppc-embedded
In-Reply-To: <20060330003419.3FF71353A37@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 3251 bytes --]
Sent this to Wolfgang last night. Accidently omitted Syvain and the list.
The actual bestcomm "microcode" in Sylvain's tree is the same as the latest
Freescale supported code. The linux driver code that interfaces with it is
code written by Dale Farnsworth and has Montavista copyright. I don't know
if it is based on old Freescale (Motorola) code or if it is Dale's creation
(perhaps Dale can comment).
I have just spent some time getting UDMA support into the ATA driver using
the the bestcomm code in Sylvain's tree. In the process I found some bugs
in the code that may explain some problems people have seen with the FEC
driver. I'll try to get the patch out tomorrow.
The ATA driver is a port from a version that worked on an older kernel and
used the supported Freescale Bestcomm code. I did the port because it was
my understanding that attempts to get the supported Freescale code into a
public tree had met with resistance in the past. (Second hand info, I'm
actually fairly new to the 52xx world).
The pluses for the Freescale version is that several devices are supported
that are not in Sylvain's tree. The version in Sylvain's kernel has a
generic api plus specific code for FEC. My upcoming patch fixes some bugs,
adds some missing functionality that I need for ATA and adds the specific
ATA dma driver code.
The biggest minus for the Freescale version is that it is really opaque.
Its implementation makes it hard to figure out what the code is actually
doing.
If there is a chance of getting the Freescale Bestcomm code into Sylvain's
tree (and on up the line to Linus) I would welcome that since I would not
have to port other Bestcomm dependent drivers to the version in Sylvain's
tree. I would gladly port the current FEC code to the Freescale Bestcomm
code to avoid the work of porting the other drivers. Also we at Freescale
would prefer to have one version of the Bestcomm code circulating.
So I guess my question for those with an opinion is what version of Bestcomm
should be we use for 5200.
Thanks for your input
John
On 3/29/06, Wolfgang Denk <wd@denx.de> wrote:
>
> In message <442B11E8.7020107@246tNt.com> you wrote:
> >
> > It is ?
>
> I think so.
>
> > I don't know about the 2.6-denx, but the stock 2.6.15 should work just
> fine.
> > What's wrong with it ? (except it misses some drivers ... it should
> compile
> > and boot just fine)
>
> Isn't the current reengineered implementation of the BestComm code
> based on an very old Freescale version, which has known limitations
> and problems?
>
> Or has there any action resulted out of the discussion with the
> Freescale engineers, and I have missed it?
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> In accord with UNIX philosophy, Perl gives you enough rope to hang
> yourself. - L. Wall & R. L. Schwartz, _Programming Perl_
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 4093 bytes --]
^ permalink raw reply
* Re: pci-x
From: Andy Fleming @ 2006-03-30 16:28 UTC (permalink / raw)
To: Carlos Mitidieri; +Cc: linuxppc-embedded
In-Reply-To: <200603281651.53196.carlos.mitidieri@sysgo.com>
On Mar 28, 2006, at 08:51, Carlos Mitidieri wrote:
>
>> On Friday 24 March 2006 15:53, Kumar Gala wrote:
>>> That seems like a driver problem. Does lspci show your devices
>>> after
>>> you boot? Also, what kernel ver are you using?
>>
>> No, the device behind the bridge is not recognized, although the
>> bridge
>> itself is. I am using kernel 2.6.15.
>
> I am trying to use a PCI-X bridge (Intel 31154) on a mpc8540ads
> running kernel
> 2.6.15. A USB controller is behind the bridge.
>
> When the mpc8540ads is booted with the PCI-X switch disabled, the
> device
> behind the bridge is detected (and actually works), and the following
> messages are printed:
Are you using a Rev A or higher board? PCI-X doesn't work on earlier
systems.
Also, make sure your board is configured to run PCI at 66 MHz. PCI-X
doesn't work at 33 MHz.
Andy Fleming
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Vitaly Bordug @ 2006-03-30 15:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <3A2715AD-F459-4AB3-B01B-13301BE2B908@kernel.crashing.org>
On Thu, 30 Mar 2006 09:43:38 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Mar 30, 2006, at 9:14 AM, Dan Malek wrote:
>
> >
> > On Mar 30, 2006, at 9:37 AM, Kumar Gala wrote:
> >
> >> * What a give channel (SCC, FCC, UCC, SMC?) is used for serial,
> >> ethernet, ATM, etc.
> >
> > You need to view this from the other direction. As I've always
> > said, we don't have an "SCC driver", we have a uart driver for
> > SCCs. So, you configure from that perspective. The uart driver
> > is configured to use certain SCCs.
>
> Oh, I agree with you. This becomes more obvious with QE where
> everything is a UCC channel.
>
> >> * How a channel is wired? [pin muxing] (I really hate having drivers
> >> have board specific ifdefs for this)
> >
> > I've got a solution for IO pin multiplexing that I have to get pushed
> > in using the "feature_call" method like a pmac. The other thing
> > to realize here is there is often hardware beyond just "pin muxing"
> > that is unique to a board and requires configuration. Statically
> > describing what pins set/clear is a small, and already understood
> > part, of more complex set up that needs to be done with code
> > unique to a board.
>
> still waiting :)
>
> >> * which (if any) BRG a channel is using?
> >
> > These are already a dynamically allocated resource. Drivers
> > don't care which one is assigned, you should be allocating
> > one and using the handle provided to the support functions.
>
> Ok, good.
>
> >> * ...? [I feel like I'm missing some but haven't worked on a CPM
> >> driver in a while :)]
> >
> > I can't think of any, and I use the CPM all of the time. :-)
> >
> >> The other question is what changes between CPUs?
> >
> > Almost nothing, except the PRAM offset you mention below
> > and I've mentioned in past messages as memory bank differences.
> >
> >> * Number/Mix of channels
> >> * some PRAM offset (8272 FCC comes to mind)
> >> * channel differences for same channel type? (what's an example of
> >> this?)
> >> * ...?
> >
> > Don't be creating problems to solve because we seem to have
> > a solution for _something_. Yes, this would be a cute piece of code
> > to write and interesting driver updates, but in the end all we have
> > is change for the sake of change, without adding any new features.
>
> I'm hopefully not suggesting that or at least not something I see as
> this extensive.
>
> > The thing to remember is the few public Linux drivers we have
> > take little advantage of the CPM features. We just configure a few
> > fixed standard modes (like serial and Ethernet). The CPM is far
> > more powerful and flexible than this, so it seems silly to create some
> > complex method of describing our trivial fixed modes that has no
> > hope of actually being useful for "real" CPM usage. Then, when
> > someone does write a more complex driver, we have all of this
> > "framework" that just gets in the way instead of being useful.
>
> I know.
>
> I guess what I'd suggest is something that makes letting the kernel
> know about serial & enet usage on the CPM is the extent to take this
> to start with. If in time we have more drivers for more things
> great, then extend it then. I dont see any reason we can't leverage
> the flat-dev-tree to have a single way to describe the serial & enet
> configs for a board.
>
Yes, that's definitely what it is intended to be...
> I see how you can see this as duplication of a solved problem.
> However, we need some place to describe some basic config info that
> we have in arch/ppc for arch/powerpc and flat-dev/.dts is that
> mechanism. While we are moving it out of the kernel proper, I think
> the idea is that over time using the flat-dev tree will allow the
> information we have to be described in one place and shared between
> kernel & firmware.
>
And the results we have now for 85xx family look very nice using this approach.
> (and if Vitaly finishes this off we can beat him up to add kgdb
> support back to cpm_uart :)
Hrm, I've added that to kgdb already... I even have the KGDB stuff implemented in the platform-device-reworked cpm_uart driver :)
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Vitaly Bordug @ 2006-03-30 15:02 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <9ede6f664a3419c5dda34c5e1911a7e6@embeddedalley.com>
On Thu, 30 Mar 2006 10:14:18 -0500
Dan Malek <dan@embeddedalley.com> wrote:
>
> On Mar 30, 2006, at 9:37 AM, Kumar Gala wrote:
>
> > * What a give channel (SCC, FCC, UCC, SMC?) is used for serial,
> > ethernet, ATM, etc.
>
> You need to view this from the other direction. As I've always
> said, we don't have an "SCC driver", we have a uart driver for
> SCCs. So, you configure from that perspective. The uart driver
> is configured to use certain SCCs.
>
Well, I am going to move the board-specific code to the BSP place, and make the driver use the callback when it needs to configure the HW tp use SCC/SMC (that includes pin setup as well - the way it is in fs_enet). Actually, it can use any (or even all the SXCs) simultaneously, and that strict configuration can be obsoleted (I mean - nothing required in .config to mention which soc device has the uart, as gianfar does not require what TSEC to utilize) - people often misconfigure things, and to be right there should be ifdef hell in the driver which is _odd_.
> > * How a channel is wired? [pin muxing] (I really hate having drivers
> > have board specific ifdefs for this)
>
> I've got a solution for IO pin multiplexing that I have to get pushed
> in using the "feature_call" method like a pmac. The other thing
> to realize here is there is often hardware beyond just "pin muxing"
> that is unique to a board and requires configuration. Statically
> describing what pins set/clear is a small, and already understood
> part, of more complex set up that needs to be done with code
> unique to a board.
well, ... :D
>
> > * which (if any) BRG a channel is using?
>
> These are already a dynamically allocated resource. Drivers
> don't care which one is assigned, you should be allocating
> one and using the handle provided to the support functions.
>
Nobody is arguing. But we need offsets to deal with BRGs (at least repeat that behavior in powerpc), CMX, CP - and there are 2 options to have them - yet another foo_immap.h or that "static" nodes in the flattened device tree.
We already have mature implementation of the first approach - and I just want to give the second one a try and to see if it will be more flexible/effective that what we have in ppc right now.
> > * ...? [I feel like I'm missing some but haven't worked on a CPM
> > driver in a while :)]
>
> I can't think of any, and I use the CPM all of the time. :-)
That is great :)
>
> > The other question is what changes between CPUs?
>
> Almost nothing, except the PRAM offset you mention below
> and I've mentioned in past messages as memory bank differences.
>
> > * Number/Mix of channels
> > * some PRAM offset (8272 FCC comes to mind)
> > * channel differences for same channel type? (what's an example of
> > this?)
> > * ...?
>
> Don't be creating problems to solve because we seem to have
> a solution for _something_. Yes, this would be a cute piece of code
> to write and interesting driver updates, but in the end all we have
> is change for the sake of change, without adding any new features.
Let me disagree. Each big change is "a change for change, for design" usually at start. Or, why don't we still use 2.4 - I'm pretty sure there was some period of "redesign" when the new architecture tries to re-implement features yet-existing in mature-stable branch... Or am I missing something?
>
> The thing to remember is the few public Linux drivers we have
> take little advantage of the CPM features. We just configure a few
> fixed standard modes (like serial and Ethernet). The CPM is far
> more powerful and flexible than this, so it seems silly to create some
> complex method of describing our trivial fixed modes that has no
> hope of actually being useful for "real" CPM usage. Then, when
> someone does write a more complex driver, we have all of this
> "framework" that just gets in the way instead of being useful.
>
Currently we'll be stale on that small fixed functionality with the implementation we have in ppc. Yes, feature_call could help, but will not save the world, so drivers will have that ifdeffed code inside, direct immr dereference, etc. Well, it's really hard to make use of CPM flexibility the way it is now. I don't believe that devicetree approach will save the world either, but it is promising enough at least to try that way.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Kumar Gala @ 2006-03-30 15:43 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <9ede6f664a3419c5dda34c5e1911a7e6@embeddedalley.com>
On Mar 30, 2006, at 9:14 AM, Dan Malek wrote:
>
> On Mar 30, 2006, at 9:37 AM, Kumar Gala wrote:
>
>> * What a give channel (SCC, FCC, UCC, SMC?) is used for serial,
>> ethernet, ATM, etc.
>
> You need to view this from the other direction. As I've always
> said, we don't have an "SCC driver", we have a uart driver for
> SCCs. So, you configure from that perspective. The uart driver
> is configured to use certain SCCs.
Oh, I agree with you. This becomes more obvious with QE where
everything is a UCC channel.
>> * How a channel is wired? [pin muxing] (I really hate having drivers
>> have board specific ifdefs for this)
>
> I've got a solution for IO pin multiplexing that I have to get pushed
> in using the "feature_call" method like a pmac. The other thing
> to realize here is there is often hardware beyond just "pin muxing"
> that is unique to a board and requires configuration. Statically
> describing what pins set/clear is a small, and already understood
> part, of more complex set up that needs to be done with code
> unique to a board.
still waiting :)
>> * which (if any) BRG a channel is using?
>
> These are already a dynamically allocated resource. Drivers
> don't care which one is assigned, you should be allocating
> one and using the handle provided to the support functions.
Ok, good.
>> * ...? [I feel like I'm missing some but haven't worked on a CPM
>> driver in a while :)]
>
> I can't think of any, and I use the CPM all of the time. :-)
>
>> The other question is what changes between CPUs?
>
> Almost nothing, except the PRAM offset you mention below
> and I've mentioned in past messages as memory bank differences.
>
>> * Number/Mix of channels
>> * some PRAM offset (8272 FCC comes to mind)
>> * channel differences for same channel type? (what's an example of
>> this?)
>> * ...?
>
> Don't be creating problems to solve because we seem to have
> a solution for _something_. Yes, this would be a cute piece of code
> to write and interesting driver updates, but in the end all we have
> is change for the sake of change, without adding any new features.
I'm hopefully not suggesting that or at least not something I see as
this extensive.
> The thing to remember is the few public Linux drivers we have
> take little advantage of the CPM features. We just configure a few
> fixed standard modes (like serial and Ethernet). The CPM is far
> more powerful and flexible than this, so it seems silly to create some
> complex method of describing our trivial fixed modes that has no
> hope of actually being useful for "real" CPM usage. Then, when
> someone does write a more complex driver, we have all of this
> "framework" that just gets in the way instead of being useful.
I know.
I guess what I'd suggest is something that makes letting the kernel
know about serial & enet usage on the CPM is the extent to take this
to start with. If in time we have more drivers for more things
great, then extend it then. I dont see any reason we can't leverage
the flat-dev-tree to have a single way to describe the serial & enet
configs for a board.
I see how you can see this as duplication of a solved problem.
However, we need some place to describe some basic config info that
we have in arch/ppc for arch/powerpc and flat-dev/.dts is that
mechanism. While we are moving it out of the kernel proper, I think
the idea is that over time using the flat-dev tree will allow the
information we have to be described in one place and shared between
kernel & firmware.
(and if Vitaly finishes this off we can beat him up to add kgdb
support back to cpm_uart :)
- kumar
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Dan Malek @ 2006-03-30 15:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <EE317557-1474-41EE-B746-22B6C275905F@kernel.crashing.org>
On Mar 30, 2006, at 9:37 AM, Kumar Gala wrote:
> * What a give channel (SCC, FCC, UCC, SMC?) is used for serial,
> ethernet, ATM, etc.
You need to view this from the other direction. As I've always
said, we don't have an "SCC driver", we have a uart driver for
SCCs. So, you configure from that perspective. The uart driver
is configured to use certain SCCs.
> * How a channel is wired? [pin muxing] (I really hate having drivers
> have board specific ifdefs for this)
I've got a solution for IO pin multiplexing that I have to get pushed
in using the "feature_call" method like a pmac. The other thing
to realize here is there is often hardware beyond just "pin muxing"
that is unique to a board and requires configuration. Statically
describing what pins set/clear is a small, and already understood
part, of more complex set up that needs to be done with code
unique to a board.
> * which (if any) BRG a channel is using?
These are already a dynamically allocated resource. Drivers
don't care which one is assigned, you should be allocating
one and using the handle provided to the support functions.
> * ...? [I feel like I'm missing some but haven't worked on a CPM
> driver in a while :)]
I can't think of any, and I use the CPM all of the time. :-)
> The other question is what changes between CPUs?
Almost nothing, except the PRAM offset you mention below
and I've mentioned in past messages as memory bank differences.
> * Number/Mix of channels
> * some PRAM offset (8272 FCC comes to mind)
> * channel differences for same channel type? (what's an example of
> this?)
> * ...?
Don't be creating problems to solve because we seem to have
a solution for _something_. Yes, this would be a cute piece of code
to write and interesting driver updates, but in the end all we have
is change for the sake of change, without adding any new features.
The thing to remember is the few public Linux drivers we have
take little advantage of the CPM features. We just configure a few
fixed standard modes (like serial and Ethernet). The CPM is far
more powerful and flexible than this, so it seems silly to create some
complex method of describing our trivial fixed modes that has no
hope of actually being useful for "real" CPM usage. Then, when
someone does write a more complex driver, we have all of this
"framework" that just gets in the way instead of being useful.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Kumar Gala @ 2006-03-30 14:37 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <0f0e0fbbf56f73879a70f785c497756c@embeddededge.com>
On Mar 30, 2006, at 7:09 AM, Dan Malek wrote:
>
> On Mar 30, 2006, at 5:26 AM, Vitaly Bordug wrote:
>
>> - the new way, all that will not follow it will be obsoleted sooner
>> or later
>
> The problem I see is the "new way" is done for the sake of doing
> something
> new, without adding any value. If you want to make the drivers
> dynamically
> configurable, which I'll continue to argue is silly in an embedded
> environment
> of the type with CPMs, all you need to know is personality of the
> device.
> The reason it's silly is the wiring on the particular board dictates
> how a
> CPM peripheral will be used. The SCC1 can't be a serial uart one
> moment and an Ethernet the next time you boot up. Since you have
> already
> done a "board port", you may as well wire this as part of the
> configuration
> and eliminate potential mistakes. If you insist on making this
> dynamic
> (and as a port maintainer I would reject such patches), the only thing
> you need to describe is the device type. For example, the SCC1 can be
> an Ethernet or uart. We only support FCCs as Ethernets, and unless
> someone submits some other kind of driver, like ATM/UTOPIA, there
> isn't anything variable to configure.
>
> All of the truly configurable options, like NMSI vs. TSA, are so
> complex
> the device tree would not be helpful, as that would be built into the
> custom driver to configure as necessary.
>
> The offsets into the internal register maps are not so variable that
> adding
> the information into the device tree is useful. There is CPM1 and
> CPM2,
> some common code shared between them that already solves the
> problems, and the real difference between the two different CPM2 maps
> on 82xx isn't reflected here (but again is already solved in the
> existing
> software). As I said in the past message, this seems more likely to
> cause
> errors than be helpful. To me it just seems new for the sake of being
> new, rather than providing any real value.
>
> I'd rather we spend our time adding the xmon and kgdb over serial port
> features back into the driver that were lost during the "great driver
> clean up"
> than pursing stuff like this.
Maybe we should look at this from a different point of view. What
are the things that change can change between boards for the same CPU?
* What a give channel (SCC, FCC, UCC, SMC?) is used for serial,
ethernet, ATM, etc.
* How a channel is wired? [pin muxing] (I really hate having drivers
have board specific ifdefs for this)
* which (if any) BRG a channel is using?
* ...? [I feel like I'm missing some but haven't worked on a CPM
driver in a while :)]
The other question is what changes between CPUs?
* Number/Mix of channels
* some PRAM offset (8272 FCC comes to mind)
* channel differences for same channel type? (what's an example of
this?)
* ...?
I think we should attempt to answer my two questions first (which Dan
took an initial swag at) and use those answers to drive how/what we
need in the description of a CPM node.
- kumar
^ permalink raw reply
* Re: snd-aoa: new apple sound driver
From: Johannes Berg @ 2006-03-30 14:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc, Alastair Poole
In-Reply-To: <1143673907.32206.19.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 4391 bytes --]
On Thu, 2006-03-30 at 10:11 +1100, Benjamin Herrenschmidt wrote:
> Yes, but we should probably still mute the amps... especially when using
> a separate analog codec (like tas3004 + topaz setups).
Hah ok, are those on the same i2s bus? Hrm. No actually, I don't think
we *have to* mute the amps since in that case, we really should be
turning off the tas3004 anyway so it doesn't even try to create analog
output from the digital 'noise' it's getting. That shouldn't be too hard
to add in that case. Though, the current framework can't do that.
Bugger. I'll have to think about how to export the correct capabilities
to userspace, onyx is currently playing some tricks to get it right :/
Ok, this isn't hard to handle. Right now, we intersect all possible
formats that are registered in all codecs on a soundbus device. This has
to change to intersect all transport_infos within a codec, and then
combine these over the codecs. Something like:
$$\mbox{allowed} = \bigcup_{c \in \mbox{codecs}} \, \bigcap_{t \in \{\mbox{transfers of c}\}} t$$
(http://johannes.sipsolutions.net/snd-aoa-formula)
Then the codecs are notified whichever format userland chooses, and can
then disable themselves if necessary. That should work fine. Initially,
I assumed just doing a big intersection would be ok, but it can't work
across codecs. Within a codec, it is manageable, look into onyx :)
> I was thinking about an event based mecanism... snd-aoa has an array of
> all inputs & outputs, which codec handles them, and, if relevant,
> handles to connector detect GPIOs and amp mute GPIOs.
Yeah, sounds good. Except that the fabric needs the array.
> Clock refcounting will be done ... some other time :)
:)
> And you need to turn the clock off for that ? All the FCRs are useful
> for you is to turn the clock input on and off, you shouldn't need that
> except when switching to an external clock no ? And even then ... AFAIK,
> Darwin AppleOnBoardAudio isn't playing with those FCRs at all unless
> I've missed something, all it does is to call in PowerI2S via platform
> calls to AppleKeyLargo which is equivalent to the existing pmac feature
> call...
I need to turn off the clock to the cell, not the clock. Something that
I'm currently doing by calling the platform cell-enable function. I
think that's all that is needed to be able to change the data word sizes
and serial format registers. Will look a bit more in darwin, it's
commented in the legacy audio stuff I think.
> How so ? autoloading only works for devices on a bus type known by the
> autoloader.. like macio. Thus other modules won't autoload unless you
> have a bus type that supports the loading stuff for hotplug and
> appropriate scripts... macio has such things, I don't think it will
> handle your soundbus though without some changes, and the modules
> themselves must expose via tables what they match on. I'm not sure I
> fully understand what you are expecting there
Ah heh, I thought the userland would just try to load modules for *any*
device that shows up based on the modalias, i.e. "device shows up
in /sys/devices" => "modprobe `cat /sys/device/<new>/modalias`"
> Maybe you aren;t getting the right addresses for it from OF :) I told
> you there are some dodgy things going on with the device-tree ... I
> think tx is at 0x8000 and rx at 0x8100 inside the MacIO ASIC (thus
> 0x8008000 and 0x8008100). Another possibility is that you are
> programming it wrong or haven't enabled something somewhere in the codec
> to actually emit data :) I'll have a look as soon as I manage to find
> some time. Maybe on the plane this week-end.
If the codec wasn't emitting data, then I should still record silence on
the i2s bus, no? Clocking is done by the i2s cell. But I'm not too sure
about this, I don't know where the problem is. I think the address is ok
though.
> > yeah. It's slightly more complicated unless we assume that the control
> > interface (i2c) is always available, because we'd also get power
> > management through the i2c device stuff.
>
> It is always available. Just ignore PM callbacks from i2c
Ok. But seeing that the soundbus stuff is generic enough, I may want to
still handle that kind of situation. Or maybe not. Haven't decided yet,
probably depends on how hard handling it really is.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa: new apple sound driver
From: Johannes Berg @ 2006-03-30 13:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc, Alastair Poole
In-Reply-To: <1143672819.32206.1.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 490 bytes --]
On Thu, 2006-03-30 at 09:53 +1100, Benjamin Herrenschmidt wrote:
> On the laptop.
>
> Mar 29 11:11:51 localhost kernel: [ 192.069735] i2sbus: found i2s
> controller
> Mar 29 11:11:51 localhost kernel: [ 192.069752] soundbus: adding device
> failed sanity check!
> Mar 29 11:11:51 localhost kernel: [ 192.069757] i2sbus: device
> registration error!
That is, umm, weird. But it shouldn't cause the module to crash either
way so I'll force it and look into it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Dan Malek @ 2006-03-30 13:09 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060330142626.1a9d22f5@vitb.ru.mvista.com>
On Mar 30, 2006, at 5:26 AM, Vitaly Bordug wrote:
> - the new way, all that will not follow it will be obsoleted sooner
> or later
The problem I see is the "new way" is done for the sake of doing
something
new, without adding any value. If you want to make the drivers
dynamically
configurable, which I'll continue to argue is silly in an embedded
environment
of the type with CPMs, all you need to know is personality of the
device.
The reason it's silly is the wiring on the particular board dictates
how a
CPM peripheral will be used. The SCC1 can't be a serial uart one
moment and an Ethernet the next time you boot up. Since you have
already
done a "board port", you may as well wire this as part of the
configuration
and eliminate potential mistakes. If you insist on making this dynamic
(and as a port maintainer I would reject such patches), the only thing
you need to describe is the device type. For example, the SCC1 can be
an Ethernet or uart. We only support FCCs as Ethernets, and unless
someone submits some other kind of driver, like ATM/UTOPIA, there
isn't anything variable to configure.
All of the truly configurable options, like NMSI vs. TSA, are so complex
the device tree would not be helpful, as that would be built into the
custom driver to configure as necessary.
The offsets into the internal register maps are not so variable that
adding
the information into the device tree is useful. There is CPM1 and CPM2,
some common code shared between them that already solves the
problems, and the real difference between the two different CPM2 maps
on 82xx isn't reflected here (but again is already solved in the
existing
software). As I said in the past message, this seems more likely to
cause
errors than be helpful. To me it just seems new for the sake of being
new, rather than providing any real value.
I'd rather we spend our time adding the xmon and kgdb over serial port
features back into the driver that were lost during the "great driver
clean up"
than pursing stuff like this.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] PowerMac11,2 i2c-bus@0 duplicate dev-tree workaround
From: Johannes Berg @ 2006-03-30 13:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1143692765.16706.10.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]
On Thu, 2006-03-30 at 15:26 +1100, Benjamin Herrenschmidt wrote:
> Hrm... you set allnextpp to NULL ... won't that prevent any further node
> from being enqueued in the global node list ?
No, it only prevents all *child* nodes, since the function recurses so
once you go out allnextpp is valid again. I'm not setting *allnextpp :)
> In fact, I think the workaround should be in prom_init.c when
> flattening... easier to skip a node there, and that's also where you are
> reasonably sure of getting the nodes in the right order, not when
> unflattening.
Ok. I'll look at that code then.
> Also, you don't even need to test for PowerMac11,2 .. .prom_init.c
> already has a machine type, so just test that it's a mac and has this
> node duplicated, and if yes, remove the dup. In fact, you could probably
> even run a bit of forth with "interpret" to do so before the tree is
> even walked though :)
Heh. Well, if you tell me what you prefer I'll try to do it. Meanwhile
I'll use this patch so the sound stuff etc. doesn't get too confusing
(it keeps telling me about two onyx codecs found...)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* [PATCH] Change H_StudlyCaps to H_SHOUTING_CAPS
From: Segher Boessenkool @ 2006-03-30 12:49 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
[I hope I got my mailer script to work okay, don't kill me please.]
Also cleans up some nearby whitespace problems.
Signed-of-by: Segher Boessenkool <segher@kernel.crashing.org>
---
arch/powerpc/kernel/lparcfg.c | 22 ++---
arch/powerpc/kernel/rtas.c | 12 +-
arch/powerpc/platforms/pseries/hvconsole.c | 6 -
arch/powerpc/platforms/pseries/hvcserver.c | 22 ++---
arch/powerpc/platforms/pseries/lpar.c | 28 +++---
arch/powerpc/platforms/pseries/setup.c | 2
arch/powerpc/platforms/pseries/vio.c | 4
arch/powerpc/platforms/pseries/xics.c | 8 -
drivers/char/hvcs.c | 2
drivers/net/ibmveth.c | 30 +++----
drivers/scsi/ibmvscsi/rpa_vscsi.c | 10 +-
include/asm-powerpc/hvcall.h | 85 +++++++++++----------
12 files changed, 119 insertions(+), 112 deletions(-)
Index: linux-2.6/arch/powerpc/kernel/lparcfg.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/lparcfg.c
+++ linux-2.6/arch/powerpc/kernel/lparcfg.c
@@ -149,17 +149,17 @@
if (rc == 0) /* success, return */
return;
/* check for null tag ? */
- if (rc == H_Hardware)
+ if (rc == H_HARDWARE)
printk(KERN_INFO
"plpar-hcall (%s) failed with hardware fault\n", tag);
- else if (rc == H_Function)
+ else if (rc == H_FUNCTION)
printk(KERN_INFO
"plpar-hcall (%s) failed; function not allowed\n", tag);
- else if (rc == H_Authority)
+ else if (rc == H_AUTHORITY)
printk(KERN_INFO
- "plpar-hcall (%s) failed; not authorized to this function\n",
- tag);
- else if (rc == H_Parameter)
+ "plpar-hcall (%s) failed; not authorized to this"
+ " function\n", tag);
+ else if (rc == H_PARAMETER)
printk(KERN_INFO "plpar-hcall (%s) failed; Bad parameter(s)\n",
tag);
else
@@ -209,7 +209,7 @@
unsigned long dummy;
rc = plpar_hcall(H_PIC, 0, 0, 0, 0, pool_idle_time, num_procs, &dummy);
- if (rc != H_Authority)
+ if (rc != H_AUTHORITY)
log_plpar_hcall_return(rc, "H_PIC");
}
@@ -529,13 +529,13 @@
retval = plpar_hcall_norets(H_SET_PPP, *new_entitled_ptr,
*new_weight_ptr);
- if (retval == H_Success || retval == H_Constrained) {
+ if (retval == H_SUCCESS || retval == H_CONSTRAINED) {
retval = count;
- } else if (retval == H_Busy) {
+ } else if (retval == H_BUSY) {
retval = -EBUSY;
- } else if (retval == H_Hardware) {
+ } else if (retval == H_HARDWARE) {
retval = -EIO;
- } else if (retval == H_Parameter) {
+ } else if (retval == H_PARAMETER) {
retval = -EINVAL;
} else {
printk(KERN_WARNING "%s: received unknown hv return code %ld",
Index: linux-2.6/arch/powerpc/kernel/rtas.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/rtas.c
+++ linux-2.6/arch/powerpc/kernel/rtas.c
@@ -578,18 +578,18 @@
* We use "waiting" to indicate our state. As long
* as it is >0, we are still trying to all join up.
* If it goes to 0, we have successfully joined up and
- * one thread got H_Continue. If any error happens,
+ * one thread got H_CONTINUE. If any error happens,
* we set it to <0.
*/
local_irq_save(flags);
do {
rc = plpar_hcall_norets(H_JOIN);
smp_rmb();
- } while (rc == H_Success && data->waiting > 0);
- if (rc == H_Success)
+ } while (rc == H_SUCCESS && data->waiting > 0);
+ if (rc == H_SUCCESS)
goto out;
- if (rc == H_Continue) {
+ if (rc == H_CONTINUE) {
data->waiting = 0;
data->args->args[data->args->nargs] =
rtas_call(ibm_suspend_me_token, 0, 1, NULL);
@@ -597,7 +597,7 @@
plpar_hcall_norets(H_PROD,i);
} else {
data->waiting = -EBUSY;
- printk(KERN_ERR "Error on H_Join hypervisor call\n");
+ printk(KERN_ERR "Error on H_JOIN hypervisor call\n");
}
out:
@@ -624,7 +624,7 @@
printk(KERN_ERR "Error doing global join\n");
/* Prod each CPU. This won't hurt, and will wake
- * anyone we successfully put to sleep with H_Join
+ * anyone we successfully put to sleep with H_JOIN.
*/
for_each_possible_cpu(i)
plpar_hcall_norets(H_PROD, i);
Index: linux-2.6/arch/powerpc/platforms/pseries/hvconsole.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pseries/hvconsole.c
+++ linux-2.6/arch/powerpc/platforms/pseries/hvconsole.c
@@ -41,7 +41,7 @@
unsigned long got;
if (plpar_hcall(H_GET_TERM_CHAR, vtermno, 0, 0, 0, &got,
- (unsigned long *)buf, (unsigned long *)buf+1) == H_Success)
+ (unsigned long *)buf, (unsigned long *)buf+1) == H_SUCCESS)
return got;
return 0;
}
@@ -69,9 +69,9 @@
ret = plpar_hcall_norets(H_PUT_TERM_CHAR, vtermno, count, lbuf[0],
lbuf[1]);
- if (ret == H_Success)
+ if (ret == H_SUCCESS)
return count;
- if (ret == H_Busy)
+ if (ret == H_BUSY)
return 0;
return -EIO;
}
Index: linux-2.6/arch/powerpc/platforms/pseries/hvcserver.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pseries/hvcserver.c
+++ linux-2.6/arch/powerpc/platforms/pseries/hvcserver.c
@@ -43,21 +43,21 @@
static int hvcs_convert(long to_convert)
{
switch (to_convert) {
- case H_Success:
+ case H_SUCCESS:
return 0;
- case H_Parameter:
+ case H_PARAMETER:
return -EINVAL;
- case H_Hardware:
+ case H_HARDWARE:
return -EIO;
- case H_Busy:
- case H_LongBusyOrder1msec:
- case H_LongBusyOrder10msec:
- case H_LongBusyOrder100msec:
- case H_LongBusyOrder1sec:
- case H_LongBusyOrder10sec:
- case H_LongBusyOrder100sec:
+ case H_BUSY:
+ case H_LONG_BUSY_ORDER_1_MSEC:
+ case H_LONG_BUSY_ORDER_10_MSEC:
+ case H_LONG_BUSY_ORDER_100_MSEC:
+ case H_LONG_BUSY_ORDER_1_SEC:
+ case H_LONG_BUSY_ORDER_10_SEC:
+ case H_LONG_BUSY_ORDER_100_SEC:
return -EBUSY;
- case H_Function: /* fall through */
+ case H_FUNCTION: /* fall through */
default:
return -EPERM;
}
Index: linux-2.6/arch/powerpc/platforms/pseries/lpar.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pseries/lpar.c
+++ linux-2.6/arch/powerpc/platforms/pseries/lpar.c
@@ -72,7 +72,7 @@
do {
rc = plpar_put_term_char(vtermno, sizeof(packet), packet);
- } while (rc == H_Busy);
+ } while (rc == H_BUSY);
}
static long hvsi_udbg_buf_len;
@@ -85,7 +85,7 @@
if (hvsi_udbg_buf_len == 0) {
rc = plpar_get_term_char(vtermno, &hvsi_udbg_buf_len, hvsi_udbg_buf);
- if (rc != H_Success || hvsi_udbg_buf[0] != 0xff) {
+ if (rc != H_SUCCESS || hvsi_udbg_buf[0] != 0xff) {
/* bad read or non-data packet */
hvsi_udbg_buf_len = 0;
} else {
@@ -139,7 +139,7 @@
buf[0] = c;
do {
rc = plpar_put_term_char(vtermno, 1, buf);
- } while(rc == H_Busy);
+ } while(rc == H_BUSY);
}
/* Buffered chars getc */
@@ -158,7 +158,7 @@
/* get some more chars. */
inbuflen = 0;
rc = plpar_get_term_char(vtermno, &inbuflen, buf);
- if (rc != H_Success)
+ if (rc != H_SUCCESS)
inbuflen = 0; /* otherwise inbuflen is garbage */
}
if (inbuflen <= 0 || inbuflen > 16) {
@@ -304,7 +304,7 @@
lpar_rc = plpar_hcall(H_ENTER, flags, hpte_group, hpte_v,
hpte_r, &slot, &dummy0, &dummy1);
- if (unlikely(lpar_rc == H_PTEG_Full)) {
+ if (unlikely(lpar_rc == H_PTEG_FULL)) {
if (!(vflags & HPTE_V_BOLTED))
DBG_LOW(" full\n");
return -1;
@@ -315,7 +315,7 @@
* will fail. However we must catch the failure in hash_page
* or we will loop forever, so return -2 in this case.
*/
- if (unlikely(lpar_rc != H_Success)) {
+ if (unlikely(lpar_rc != H_SUCCESS)) {
if (!(vflags & HPTE_V_BOLTED))
DBG_LOW(" lpar err %d\n", lpar_rc);
return -2;
@@ -346,9 +346,9 @@
/* don't remove a bolted entry */
lpar_rc = plpar_pte_remove(H_ANDCOND, hpte_group + slot_offset,
(0x1UL << 4), &dummy1, &dummy2);
- if (lpar_rc == H_Success)
+ if (lpar_rc == H_SUCCESS)
return i;
- BUG_ON(lpar_rc != H_Not_Found);
+ BUG_ON(lpar_rc != H_NOT_FOUND);
slot_offset++;
slot_offset &= 0x7;
@@ -391,14 +391,14 @@
lpar_rc = plpar_pte_protect(flags, slot, want_v & HPTE_V_AVPN);
- if (lpar_rc == H_Not_Found) {
+ if (lpar_rc == H_NOT_FOUND) {
DBG_LOW("not found !\n");
return -1;
}
DBG_LOW("ok\n");
- BUG_ON(lpar_rc != H_Success);
+ BUG_ON(lpar_rc != H_SUCCESS);
return 0;
}
@@ -417,7 +417,7 @@
lpar_rc = plpar_pte_read(flags, slot, &dword0, &dummy_word1);
- BUG_ON(lpar_rc != H_Success);
+ BUG_ON(lpar_rc != H_SUCCESS);
return dword0;
}
@@ -468,7 +468,7 @@
flags = newpp & 7;
lpar_rc = plpar_pte_protect(flags, slot, 0);
- BUG_ON(lpar_rc != H_Success);
+ BUG_ON(lpar_rc != H_SUCCESS);
}
static void pSeries_lpar_hpte_invalidate(unsigned long slot, unsigned long va,
@@ -484,10 +484,10 @@
want_v = hpte_encode_v(va, psize);
lpar_rc = plpar_pte_remove(H_AVPN, slot, want_v & HPTE_V_AVPN,
&dummy1, &dummy2);
- if (lpar_rc == H_Not_Found)
+ if (lpar_rc == H_NOT_FOUND)
return;
- BUG_ON(lpar_rc != H_Success);
+ BUG_ON(lpar_rc != H_SUCCESS);
}
/*
Index: linux-2.6/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pseries/setup.c
+++ linux-2.6/arch/powerpc/platforms/pseries/setup.c
@@ -463,7 +463,7 @@
* very low priority. The cede enables interrupts, which
* doesn't matter here.
*/
- if (!lppaca[cpu ^ 1].idle || poll_pending() == H_Pending)
+ if (!lppaca[cpu ^ 1].idle || poll_pending() == H_PENDING)
cede_processor();
out:
Index: linux-2.6/arch/powerpc/platforms/pseries/vio.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pseries/vio.c
+++ linux-2.6/arch/powerpc/platforms/pseries/vio.c
@@ -258,7 +258,7 @@
int vio_enable_interrupts(struct vio_dev *dev)
{
int rc = h_vio_signal(dev->unit_address, VIO_IRQ_ENABLE);
- if (rc != H_Success)
+ if (rc != H_SUCCESS)
printk(KERN_ERR "vio: Error 0x%x enabling interrupts\n", rc);
return rc;
}
@@ -267,7 +267,7 @@
int vio_disable_interrupts(struct vio_dev *dev)
{
int rc = h_vio_signal(dev->unit_address, VIO_IRQ_DISABLE);
- if (rc != H_Success)
+ if (rc != H_SUCCESS)
printk(KERN_ERR "vio: Error 0x%x disabling interrupts\n", rc);
return rc;
}
Index: linux-2.6/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pseries/xics.c
+++ linux-2.6/arch/powerpc/platforms/pseries/xics.c
@@ -168,7 +168,7 @@
unsigned long return_value;
lpar_rc = plpar_xirr(&return_value);
- if (lpar_rc != H_Success)
+ if (lpar_rc != H_SUCCESS)
panic(" bad return code xirr - rc = %lx \n", lpar_rc);
return (int)return_value;
}
@@ -179,7 +179,7 @@
unsigned long val64 = value & 0xffffffff;
lpar_rc = plpar_eoi(val64);
- if (lpar_rc != H_Success)
+ if (lpar_rc != H_SUCCESS)
panic("bad return code EOI - rc = %ld, value=%lx\n", lpar_rc,
val64);
}
@@ -189,7 +189,7 @@
unsigned long lpar_rc;
lpar_rc = plpar_cppr(value);
- if (lpar_rc != H_Success)
+ if (lpar_rc != H_SUCCESS)
panic("bad return code cppr - rc = %lx\n", lpar_rc);
}
@@ -198,7 +198,7 @@
unsigned long lpar_rc;
lpar_rc = plpar_ipi(get_hard_smp_processor_id(n_cpu), value);
- if (lpar_rc != H_Success)
+ if (lpar_rc != H_SUCCESS)
panic("bad return code qirr - rc = %lx\n", lpar_rc);
}
Index: linux-2.6/drivers/char/hvcs.c
===================================================================
--- linux-2.6.orig/drivers/char/hvcs.c
+++ linux-2.6/drivers/char/hvcs.c
@@ -904,7 +904,7 @@
* It is possible the vty-server was removed after the irq was
* requested but before we have time to enable interrupts.
*/
- if (vio_enable_interrupts(vdev) == H_Success)
+ if (vio_enable_interrupts(vdev) == H_SUCCESS)
return 0;
else {
printk(KERN_ERR "HVCS: int enable failed for"
Index: linux-2.6/drivers/net/ibmveth.c
===================================================================
--- linux-2.6.orig/drivers/net/ibmveth.c
+++ linux-2.6/drivers/net/ibmveth.c
@@ -235,7 +235,7 @@
lpar_rc = h_add_logical_lan_buffer(adapter->vdev->unit_address, desc.desc);
- if(lpar_rc != H_Success) {
+ if(lpar_rc != H_SUCCESS) {
pool->free_map[free_index] = index;
pool->skbuff[index] = NULL;
pool->consumer_index--;
@@ -373,7 +373,7 @@
lpar_rc = h_add_logical_lan_buffer(adapter->vdev->unit_address, desc.desc);
- if(lpar_rc != H_Success) {
+ if(lpar_rc != H_SUCCESS) {
ibmveth_debug_printk("h_add_logical_lan_buffer failed during recycle rc=%ld", lpar_rc);
ibmveth_remove_buffer_from_pool(adapter, adapter->rx_queue.queue_addr[adapter->rx_queue.index].correlator);
}
@@ -511,7 +511,7 @@
adapter->filter_list_dma,
mac_address);
- if(lpar_rc != H_Success) {
+ if(lpar_rc != H_SUCCESS) {
ibmveth_error_printk("h_register_logical_lan failed with %ld\n", lpar_rc);
ibmveth_error_printk("buffer TCE:0x%lx filter TCE:0x%lx rxq desc:0x%lx MAC:0x%lx\n",
adapter->buffer_list_dma,
@@ -527,7 +527,7 @@
ibmveth_error_printk("unable to request irq 0x%x, rc %d\n", netdev->irq, rc);
do {
rc = h_free_logical_lan(adapter->vdev->unit_address);
- } while (H_isLongBusy(rc) || (rc == H_Busy));
+ } while (H_IS_LONG_BUSY(rc) || (rc == H_BUSY));
ibmveth_cleanup(adapter);
return rc;
@@ -556,9 +556,9 @@
do {
lpar_rc = h_free_logical_lan(adapter->vdev->unit_address);
- } while (H_isLongBusy(lpar_rc) || (lpar_rc == H_Busy));
+ } while (H_IS_LONG_BUSY(lpar_rc) || (lpar_rc == H_BUSY));
- if(lpar_rc != H_Success)
+ if(lpar_rc != H_SUCCESS)
{
ibmveth_error_printk("h_free_logical_lan failed with %lx, continuing with close\n",
lpar_rc);
@@ -693,9 +693,9 @@
desc[4].desc,
desc[5].desc,
correlator);
- } while ((lpar_rc == H_Busy) && (retry_count--));
+ } while ((lpar_rc == H_BUSY) && (retry_count--));
- if(lpar_rc != H_Success && lpar_rc != H_Dropped) {
+ if(lpar_rc != H_SUCCESS && lpar_rc != H_DROPPED) {
int i;
ibmveth_error_printk("tx: h_send_logical_lan failed with rc=%ld\n", lpar_rc);
for(i = 0; i < 6; i++) {
@@ -786,14 +786,14 @@
/* we think we are done - reenable interrupts, then check once more to make sure we are done */
lpar_rc = h_vio_signal(adapter->vdev->unit_address, VIO_IRQ_ENABLE);
- ibmveth_assert(lpar_rc == H_Success);
+ ibmveth_assert(lpar_rc == H_SUCCESS);
netif_rx_complete(netdev);
if(ibmveth_rxq_pending_buffer(adapter) && netif_rx_reschedule(netdev, frames_processed))
{
lpar_rc = h_vio_signal(adapter->vdev->unit_address, VIO_IRQ_DISABLE);
- ibmveth_assert(lpar_rc == H_Success);
+ ibmveth_assert(lpar_rc == H_SUCCESS);
more_work = 1;
goto restart_poll;
}
@@ -813,7 +813,7 @@
if(netif_rx_schedule_prep(netdev)) {
lpar_rc = h_vio_signal(adapter->vdev->unit_address, VIO_IRQ_DISABLE);
- ibmveth_assert(lpar_rc == H_Success);
+ ibmveth_assert(lpar_rc == H_SUCCESS);
__netif_rx_schedule(netdev);
}
return IRQ_HANDLED;
@@ -835,7 +835,7 @@
IbmVethMcastEnableRecv |
IbmVethMcastDisableFiltering,
0);
- if(lpar_rc != H_Success) {
+ if(lpar_rc != H_SUCCESS) {
ibmveth_error_printk("h_multicast_ctrl rc=%ld when entering promisc mode\n", lpar_rc);
}
} else {
@@ -847,7 +847,7 @@
IbmVethMcastDisableFiltering |
IbmVethMcastClearFilterTable,
0);
- if(lpar_rc != H_Success) {
+ if(lpar_rc != H_SUCCESS) {
ibmveth_error_printk("h_multicast_ctrl rc=%ld when attempting to clear filter table\n", lpar_rc);
}
/* add the addresses to the filter table */
@@ -858,7 +858,7 @@
lpar_rc = h_multicast_ctrl(adapter->vdev->unit_address,
IbmVethMcastAddFilter,
mcast_addr);
- if(lpar_rc != H_Success) {
+ if(lpar_rc != H_SUCCESS) {
ibmveth_error_printk("h_multicast_ctrl rc=%ld when adding an entry to the filter table\n", lpar_rc);
}
}
@@ -867,7 +867,7 @@
lpar_rc = h_multicast_ctrl(adapter->vdev->unit_address,
IbmVethMcastEnableFiltering,
0);
- if(lpar_rc != H_Success) {
+ if(lpar_rc != H_SUCCESS) {
ibmveth_error_printk("h_multicast_ctrl rc=%ld when enabling filtering\n", lpar_rc);
}
}
Index: linux-2.6/drivers/scsi/ibmvscsi/rpa_vscsi.c
===================================================================
--- linux-2.6.orig/drivers/scsi/ibmvscsi/rpa_vscsi.c
+++ linux-2.6/drivers/scsi/ibmvscsi/rpa_vscsi.c
@@ -80,7 +80,7 @@
tasklet_kill(&hostdata->srp_task);
do {
rc = plpar_hcall_norets(H_FREE_CRQ, vdev->unit_address);
- } while ((rc == H_Busy) || (H_isLongBusy(rc)));
+ } while ((rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
dma_unmap_single(hostdata->dev,
queue->msg_token,
queue->size * sizeof(*queue->msgs), DMA_BIDIRECTIONAL);
@@ -230,7 +230,7 @@
rc = plpar_hcall_norets(H_REG_CRQ,
vdev->unit_address,
queue->msg_token, PAGE_SIZE);
- if (rc == H_Resource)
+ if (rc == H_RESOURCE)
/* maybe kexecing and resource is busy. try a reset */
rc = ibmvscsi_reset_crq_queue(queue,
hostdata);
@@ -269,7 +269,7 @@
req_irq_failed:
do {
rc = plpar_hcall_norets(H_FREE_CRQ, vdev->unit_address);
- } while ((rc == H_Busy) || (H_isLongBusy(rc)));
+ } while ((rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
reg_crq_failed:
dma_unmap_single(hostdata->dev,
queue->msg_token,
@@ -295,7 +295,7 @@
/* Re-enable the CRQ */
do {
rc = plpar_hcall_norets(H_ENABLE_CRQ, vdev->unit_address);
- } while ((rc == H_InProgress) || (rc == H_Busy) || (H_isLongBusy(rc)));
+ } while ((rc == H_IN_PROGRESS) || (rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
if (rc)
printk(KERN_ERR "ibmvscsi: Error %d enabling adapter\n", rc);
@@ -317,7 +317,7 @@
/* Close the CRQ */
do {
rc = plpar_hcall_norets(H_FREE_CRQ, vdev->unit_address);
- } while ((rc == H_Busy) || (H_isLongBusy(rc)));
+ } while ((rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
/* Clean out the queue */
memset(queue->msgs, 0x00, PAGE_SIZE);
Index: linux-2.6/include/asm-powerpc/hvcall.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/hvcall.h
+++ linux-2.6/include/asm-powerpc/hvcall.h
@@ -4,47 +4,54 @@
#define HVSC .long 0x44000022
-#define H_Success 0
-#define H_Busy 1 /* Hardware busy -- retry later */
-#define H_Closed 2 /* Resource closed */
-#define H_Constrained 4 /* Resource request constrained to max allowed */
-#define H_InProgress 14 /* Kind of like busy */
-#define H_Pending 17 /* returned from H_POLL_PENDING */
-#define H_Continue 18 /* Returned from H_Join on success */
-#define H_LongBusyStartRange 9900 /* Start of long busy range */
-#define H_LongBusyOrder1msec 9900 /* Long busy, hint that 1msec is a good time to retry */
-#define H_LongBusyOrder10msec 9901 /* Long busy, hint that 10msec is a good time to retry */
-#define H_LongBusyOrder100msec 9902 /* Long busy, hint that 100msec is a good time to retry */
-#define H_LongBusyOrder1sec 9903 /* Long busy, hint that 1sec is a good time to retry */
-#define H_LongBusyOrder10sec 9904 /* Long busy, hint that 10sec is a good time to retry */
-#define H_LongBusyOrder100sec 9905 /* Long busy, hint that 100sec is a good time to retry */
-#define H_LongBusyEndRange 9905 /* End of long busy range */
-#define H_Hardware -1 /* Hardware error */
-#define H_Function -2 /* Function not supported */
-#define H_Privilege -3 /* Caller not privileged */
-#define H_Parameter -4 /* Parameter invalid, out-of-range or conflicting */
-#define H_Bad_Mode -5 /* Illegal msr value */
-#define H_PTEG_Full -6 /* PTEG is full */
-#define H_Not_Found -7 /* PTE was not found" */
-#define H_Reserved_DABR -8 /* DABR address is reserved by the hypervisor on this processor" */
-#define H_NoMem -9
-#define H_Authority -10
-#define H_Permission -11
-#define H_Dropped -12
-#define H_SourceParm -13
-#define H_DestParm -14
-#define H_RemoteParm -15
-#define H_Resource -16
+#define H_SUCCESS 0
+#define H_BUSY 1 /* Hardware busy -- retry later */
+#define H_CLOSED 2 /* Resource closed */
+#define H_CONSTRAINED 4 /* Resource request constrained to max allowed */
+#define H_IN_PROGRESS 14 /* Kind of like busy */
+#define H_PENDING 17 /* returned from H_POLL_PENDING */
+#define H_CONTINUE 18 /* Returned from H_Join on success */
+#define H_LONG_BUSY_START_RANGE 9900 /* Start of long busy range */
+#define H_LONG_BUSY_ORDER_1_MSEC 9900 /* Long busy, hint that 1msec \
+ is a good time to retry */
+#define H_LONG_BUSY_ORDER_10_MSEC 9901 /* Long busy, hint that 10msec \
+ is a good time to retry */
+#define H_LONG_BUSY_ORDER_100_MSEC 9902 /* Long busy, hint that 100msec \
+ is a good time to retry */
+#define H_LONG_BUSY_ORDER_1_SEC 9903 /* Long busy, hint that 1sec \
+ is a good time to retry */
+#define H_LONG_BUSY_ORDER_10_SEC 9904 /* Long busy, hint that 10sec \
+ is a good time to retry */
+#define H_LONG_BUSY_ORDER_100_SEC 9905 /* Long busy, hint that 100sec \
+ is a good time to retry */
+#define H_LONG_BUSY_END_RANGE 9905 /* End of long busy range */
+#define H_HARDWARE -1 /* Hardware error */
+#define H_FUNCTION -2 /* Function not supported */
+#define H_PRIVILEGE -3 /* Caller not privileged */
+#define H_PARAMETER -4 /* Parameter invalid, out-of-range or conflicting */
+#define H_BAD_MODE -5 /* Illegal msr value */
+#define H_PTEG_FULL -6 /* PTEG is full */
+#define H_NOT_FOUND -7 /* PTE was not found" */
+#define H_RESERVED_DABR -8 /* DABR address is reserved by the hypervisor on this processor" */
+#define H_NO_MEM -9
+#define H_AUTHORITY -10
+#define H_PERMISSION -11
+#define H_DROPPED -12
+#define H_SOURCE_PARM -13
+#define H_DEST_PARM -14
+#define H_REMOTE_PARM -15
+#define H_RESOURCE -16
/* Long Busy is a condition that can be returned by the firmware
* when a call cannot be completed now, but the identical call
* should be retried later. This prevents calls blocking in the
- * firmware for long periods of time. Annoyingly the firmware can return
+ * firmware for long periods of time. Annoyingly the firmware can return
* a range of return codes, hinting at how long we should wait before
* retrying. If you don't care for the hint, the macro below is a good
* way to check for the long_busy return codes
*/
-#define H_isLongBusy(x) ((x >= H_LongBusyStartRange) && (x <= H_LongBusyEndRange))
+#define H_IS_LONG_BUSY(x) ((x >= H_LONG_BUSY_START_RANGE) \
+ && (x <= H_LONG_BUSY_END_RANGE))
/* Flags */
#define H_LARGE_PAGE (1UL<<(63-16))
@@ -99,25 +106,25 @@
#define H_PERFMON 0x7c
#define H_MIGRATE_DMA 0x78
#define H_REGISTER_VPA 0xDC
-#define H_CEDE 0xE0
+#define H_CEDE 0xE0
#define H_CONFER 0xE4
-#define H_PROD 0xE8
+#define H_PROD 0xE8
#define H_GET_PPP 0xEC
#define H_SET_PPP 0xF0
#define H_PURR 0xF4
-#define H_PIC 0xF8
+#define H_PIC 0xF8
#define H_REG_CRQ 0xFC
#define H_FREE_CRQ 0x100
#define H_VIO_SIGNAL 0x104
#define H_SEND_CRQ 0x108
-#define H_COPY_RDMA 0x110
+#define H_COPY_RDMA 0x110
#define H_SET_XDABR 0x134
#define H_STUFF_TCE 0x138
#define H_PUT_TCE_INDIRECT 0x13C
#define H_VTERM_PARTNER_INFO 0x150
#define H_REGISTER_VTERM 0x154
#define H_FREE_VTERM 0x158
-#define H_POLL_PENDING 0x1D8
+#define H_POLL_PENDING 0x1D8
#define H_JOIN 0x298
#define H_ENABLE_CRQ 0x2B0
@@ -152,7 +159,7 @@
*/
long plpar_hcall_8arg_2ret(unsigned long opcode,
unsigned long arg1,
- unsigned long arg2,
+ unsigned long arg2,
unsigned long arg3,
unsigned long arg4,
unsigned long arg5,
^ permalink raw reply
* [PATCH] Change H_StudlyCaps to H_SHOUTING_CAPS
From: Segher Boessenkool @ 2006-03-30 11:58 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
[I hope I got my mailer script to work okay, don't kill me please.]
Also cleans up some nearby whitespace problems.
Signed-of-by: Segher Boessenkool <segher@kernel.crashing.org>
---
arch/powerpc/kernel/lparcfg.c | 22 ++---
arch/powerpc/kernel/rtas.c | 12 +-
arch/powerpc/platforms/pseries/hvconsole.c | 6 -
arch/powerpc/platforms/pseries/hvcserver.c | 22 ++---
arch/powerpc/platforms/pseries/lpar.c | 28 +++---
arch/powerpc/platforms/pseries/setup.c | 2
arch/powerpc/platforms/pseries/vio.c | 4
arch/powerpc/platforms/pseries/xics.c | 8 -
drivers/char/hvcs.c | 2
drivers/net/ibmveth.c | 30 +++----
drivers/scsi/ibmvscsi/rpa_vscsi.c | 10 +-
include/asm-powerpc/hvcall.h | 85 +++++++++++----------
12 files changed, 119 insertions(+), 112 deletions(-)
Index: linux-2.6/arch/powerpc/kernel/lparcfg.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/lparcfg.c
+++ linux-2.6/arch/powerpc/kernel/lparcfg.c
@@ -149,17 +149,17 @@
if (rc == 0) /* success, return */
return;
/* check for null tag ? */
- if (rc == H_Hardware)
+ if (rc == H_HARDWARE)
printk(KERN_INFO
"plpar-hcall (%s) failed with hardware fault\n", tag);
- else if (rc == H_Function)
+ else if (rc == H_FUNCTION)
printk(KERN_INFO
"plpar-hcall (%s) failed; function not allowed\n", tag);
- else if (rc == H_Authority)
+ else if (rc == H_AUTHORITY)
printk(KERN_INFO
- "plpar-hcall (%s) failed; not authorized to this function\n",
- tag);
- else if (rc == H_Parameter)
+ "plpar-hcall (%s) failed; not authorized to this"
+ " function\n", tag);
+ else if (rc == H_PARAMETER)
printk(KERN_INFO "plpar-hcall (%s) failed; Bad parameter(s)\n",
tag);
else
@@ -209,7 +209,7 @@
unsigned long dummy;
rc = plpar_hcall(H_PIC, 0, 0, 0, 0, pool_idle_time, num_procs, &dummy);
- if (rc != H_Authority)
+ if (rc != H_AUTHORITY)
log_plpar_hcall_return(rc, "H_PIC");
}
@@ -529,13 +529,13 @@
retval = plpar_hcall_norets(H_SET_PPP, *new_entitled_ptr,
*new_weight_ptr);
- if (retval == H_Success || retval == H_Constrained) {
+ if (retval == H_SUCCESS || retval == H_CONSTRAINED) {
retval = count;
- } else if (retval == H_Busy) {
+ } else if (retval == H_BUSY) {
retval = -EBUSY;
- } else if (retval == H_Hardware) {
+ } else if (retval == H_HARDWARE) {
retval = -EIO;
- } else if (retval == H_Parameter) {
+ } else if (retval == H_PARAMETER) {
retval = -EINVAL;
} else {
printk(KERN_WARNING "%s: received unknown hv return code %ld",
Index: linux-2.6/arch/powerpc/kernel/rtas.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/rtas.c
+++ linux-2.6/arch/powerpc/kernel/rtas.c
@@ -578,18 +578,18 @@
* We use "waiting" to indicate our state. As long
* as it is >0, we are still trying to all join up.
* If it goes to 0, we have successfully joined up and
- * one thread got H_Continue. If any error happens,
+ * one thread got H_CONTINUE. If any error happens,
* we set it to <0.
*/
local_irq_save(flags);
do {
rc = plpar_hcall_norets(H_JOIN);
smp_rmb();
- } while (rc == H_Success && data->waiting > 0);
- if (rc == H_Success)
+ } while (rc == H_SUCCESS && data->waiting > 0);
+ if (rc == H_SUCCESS)
goto out;
- if (rc == H_Continue) {
+ if (rc == H_CONTINUE) {
data->waiting = 0;
data->args->args[data->args->nargs] =
rtas_call(ibm_suspend_me_token, 0, 1, NULL);
@@ -597,7 +597,7 @@
plpar_hcall_norets(H_PROD,i);
} else {
data->waiting = -EBUSY;
- printk(KERN_ERR "Error on H_Join hypervisor call\n");
+ printk(KERN_ERR "Error on H_JOIN hypervisor call\n");
}
out:
@@ -624,7 +624,7 @@
printk(KERN_ERR "Error doing global join\n");
/* Prod each CPU. This won't hurt, and will wake
- * anyone we successfully put to sleep with H_Join
+ * anyone we successfully put to sleep with H_JOIN.
*/
for_each_possible_cpu(i)
plpar_hcall_norets(H_PROD, i);
Index: linux-2.6/arch/powerpc/platforms/pseries/hvconsole.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pseries/hvconsole.c
+++ linux-2.6/arch/powerpc/platforms/pseries/hvconsole.c
@@ -41,7 +41,7 @@
unsigned long got;
if (plpar_hcall(H_GET_TERM_CHAR, vtermno, 0, 0, 0, &got,
- (unsigned long *)buf, (unsigned long *)buf+1) == H_Success)
+ (unsigned long *)buf, (unsigned long *)buf+1) == H_SUCCESS)
return got;
return 0;
}
@@ -69,9 +69,9 @@
ret = plpar_hcall_norets(H_PUT_TERM_CHAR, vtermno, count, lbuf[0],
lbuf[1]);
- if (ret == H_Success)
+ if (ret == H_SUCCESS)
return count;
- if (ret == H_Busy)
+ if (ret == H_BUSY)
return 0;
return -EIO;
}
Index: linux-2.6/arch/powerpc/platforms/pseries/hvcserver.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pseries/hvcserver.c
+++ linux-2.6/arch/powerpc/platforms/pseries/hvcserver.c
@@ -43,21 +43,21 @@
static int hvcs_convert(long to_convert)
{
switch (to_convert) {
- case H_Success:
+ case H_SUCCESS:
return 0;
- case H_Parameter:
+ case H_PARAMETER:
return -EINVAL;
- case H_Hardware:
+ case H_HARDWARE:
return -EIO;
- case H_Busy:
- case H_LongBusyOrder1msec:
- case H_LongBusyOrder10msec:
- case H_LongBusyOrder100msec:
- case H_LongBusyOrder1sec:
- case H_LongBusyOrder10sec:
- case H_LongBusyOrder100sec:
+ case H_BUSY:
+ case H_LONG_BUSY_ORDER_1_MSEC:
+ case H_LONG_BUSY_ORDER_10_MSEC:
+ case H_LONG_BUSY_ORDER_100_MSEC:
+ case H_LONG_BUSY_ORDER_1_SEC:
+ case H_LONG_BUSY_ORDER_10_SEC:
+ case H_LONG_BUSY_ORDER_100_SEC:
return -EBUSY;
- case H_Function: /* fall through */
+ case H_FUNCTION: /* fall through */
default:
return -EPERM;
}
Index: linux-2.6/arch/powerpc/platforms/pseries/lpar.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pseries/lpar.c
+++ linux-2.6/arch/powerpc/platforms/pseries/lpar.c
@@ -72,7 +72,7 @@
do {
rc = plpar_put_term_char(vtermno, sizeof(packet), packet);
- } while (rc == H_Busy);
+ } while (rc == H_BUSY);
}
static long hvsi_udbg_buf_len;
@@ -85,7 +85,7 @@
if (hvsi_udbg_buf_len == 0) {
rc = plpar_get_term_char(vtermno, &hvsi_udbg_buf_len, hvsi_udbg_buf);
- if (rc != H_Success || hvsi_udbg_buf[0] != 0xff) {
+ if (rc != H_SUCCESS || hvsi_udbg_buf[0] != 0xff) {
/* bad read or non-data packet */
hvsi_udbg_buf_len = 0;
} else {
@@ -139,7 +139,7 @@
buf[0] = c;
do {
rc = plpar_put_term_char(vtermno, 1, buf);
- } while(rc == H_Busy);
+ } while(rc == H_BUSY);
}
/* Buffered chars getc */
@@ -158,7 +158,7 @@
/* get some more chars. */
inbuflen = 0;
rc = plpar_get_term_char(vtermno, &inbuflen, buf);
- if (rc != H_Success)
+ if (rc != H_SUCCESS)
inbuflen = 0; /* otherwise inbuflen is garbage */
}
if (inbuflen <= 0 || inbuflen > 16) {
@@ -304,7 +304,7 @@
lpar_rc = plpar_hcall(H_ENTER, flags, hpte_group, hpte_v,
hpte_r, &slot, &dummy0, &dummy1);
- if (unlikely(lpar_rc == H_PTEG_Full)) {
+ if (unlikely(lpar_rc == H_PTEG_FULL)) {
if (!(vflags & HPTE_V_BOLTED))
DBG_LOW(" full\n");
return -1;
@@ -315,7 +315,7 @@
* will fail. However we must catch the failure in hash_page
* or we will loop forever, so return -2 in this case.
*/
- if (unlikely(lpar_rc != H_Success)) {
+ if (unlikely(lpar_rc != H_SUCCESS)) {
if (!(vflags & HPTE_V_BOLTED))
DBG_LOW(" lpar err %d\n", lpar_rc);
return -2;
@@ -346,9 +346,9 @@
/* don't remove a bolted entry */
lpar_rc = plpar_pte_remove(H_ANDCOND, hpte_group + slot_offset,
(0x1UL << 4), &dummy1, &dummy2);
- if (lpar_rc == H_Success)
+ if (lpar_rc == H_SUCCESS)
return i;
- BUG_ON(lpar_rc != H_Not_Found);
+ BUG_ON(lpar_rc != H_NOT_FOUND);
slot_offset++;
slot_offset &= 0x7;
@@ -391,14 +391,14 @@
lpar_rc = plpar_pte_protect(flags, slot, want_v & HPTE_V_AVPN);
- if (lpar_rc == H_Not_Found) {
+ if (lpar_rc == H_NOT_FOUND) {
DBG_LOW("not found !\n");
return -1;
}
DBG_LOW("ok\n");
- BUG_ON(lpar_rc != H_Success);
+ BUG_ON(lpar_rc != H_SUCCESS);
return 0;
}
@@ -417,7 +417,7 @@
lpar_rc = plpar_pte_read(flags, slot, &dword0, &dummy_word1);
- BUG_ON(lpar_rc != H_Success);
+ BUG_ON(lpar_rc != H_SUCCESS);
return dword0;
}
@@ -468,7 +468,7 @@
flags = newpp & 7;
lpar_rc = plpar_pte_protect(flags, slot, 0);
- BUG_ON(lpar_rc != H_Success);
+ BUG_ON(lpar_rc != H_SUCCESS);
}
static void pSeries_lpar_hpte_invalidate(unsigned long slot, unsigned long va,
@@ -484,10 +484,10 @@
want_v = hpte_encode_v(va, psize);
lpar_rc = plpar_pte_remove(H_AVPN, slot, want_v & HPTE_V_AVPN,
&dummy1, &dummy2);
- if (lpar_rc == H_Not_Found)
+ if (lpar_rc == H_NOT_FOUND)
return;
- BUG_ON(lpar_rc != H_Success);
+ BUG_ON(lpar_rc != H_SUCCESS);
}
/*
Index: linux-2.6/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pseries/setup.c
+++ linux-2.6/arch/powerpc/platforms/pseries/setup.c
@@ -463,7 +463,7 @@
* very low priority. The cede enables interrupts, which
* doesn't matter here.
*/
- if (!lppaca[cpu ^ 1].idle || poll_pending() == H_Pending)
+ if (!lppaca[cpu ^ 1].idle || poll_pending() == H_PENDING)
cede_processor();
out:
Index: linux-2.6/arch/powerpc/platforms/pseries/vio.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pseries/vio.c
+++ linux-2.6/arch/powerpc/platforms/pseries/vio.c
@@ -258,7 +258,7 @@
int vio_enable_interrupts(struct vio_dev *dev)
{
int rc = h_vio_signal(dev->unit_address, VIO_IRQ_ENABLE);
- if (rc != H_Success)
+ if (rc != H_SUCCESS)
printk(KERN_ERR "vio: Error 0x%x enabling interrupts\n", rc);
return rc;
}
@@ -267,7 +267,7 @@
int vio_disable_interrupts(struct vio_dev *dev)
{
int rc = h_vio_signal(dev->unit_address, VIO_IRQ_DISABLE);
- if (rc != H_Success)
+ if (rc != H_SUCCESS)
printk(KERN_ERR "vio: Error 0x%x disabling interrupts\n", rc);
return rc;
}
Index: linux-2.6/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pseries/xics.c
+++ linux-2.6/arch/powerpc/platforms/pseries/xics.c
@@ -168,7 +168,7 @@
unsigned long return_value;
lpar_rc = plpar_xirr(&return_value);
- if (lpar_rc != H_Success)
+ if (lpar_rc != H_SUCCESS)
panic(" bad return code xirr - rc = %lx \n", lpar_rc);
return (int)return_value;
}
@@ -179,7 +179,7 @@
unsigned long val64 = value & 0xffffffff;
lpar_rc = plpar_eoi(val64);
- if (lpar_rc != H_Success)
+ if (lpar_rc != H_SUCCESS)
panic("bad return code EOI - rc = %ld, value=%lx\n", lpar_rc,
val64);
}
@@ -189,7 +189,7 @@
unsigned long lpar_rc;
lpar_rc = plpar_cppr(value);
- if (lpar_rc != H_Success)
+ if (lpar_rc != H_SUCCESS)
panic("bad return code cppr - rc = %lx\n", lpar_rc);
}
@@ -198,7 +198,7 @@
unsigned long lpar_rc;
lpar_rc = plpar_ipi(get_hard_smp_processor_id(n_cpu), value);
- if (lpar_rc != H_Success)
+ if (lpar_rc != H_SUCCESS)
panic("bad return code qirr - rc = %lx\n", lpar_rc);
}
Index: linux-2.6/drivers/char/hvcs.c
===================================================================
--- linux-2.6.orig/drivers/char/hvcs.c
+++ linux-2.6/drivers/char/hvcs.c
@@ -904,7 +904,7 @@
* It is possible the vty-server was removed after the irq was
* requested but before we have time to enable interrupts.
*/
- if (vio_enable_interrupts(vdev) == H_Success)
+ if (vio_enable_interrupts(vdev) == H_SUCCESS)
return 0;
else {
printk(KERN_ERR "HVCS: int enable failed for"
Index: linux-2.6/drivers/net/ibmveth.c
===================================================================
--- linux-2.6.orig/drivers/net/ibmveth.c
+++ linux-2.6/drivers/net/ibmveth.c
@@ -235,7 +235,7 @@
lpar_rc = h_add_logical_lan_buffer(adapter->vdev->unit_address, desc.desc);
- if(lpar_rc != H_Success) {
+ if(lpar_rc != H_SUCCESS) {
pool->free_map[free_index] = index;
pool->skbuff[index] = NULL;
pool->consumer_index--;
@@ -373,7 +373,7 @@
lpar_rc = h_add_logical_lan_buffer(adapter->vdev->unit_address, desc.desc);
- if(lpar_rc != H_Success) {
+ if(lpar_rc != H_SUCCESS) {
ibmveth_debug_printk("h_add_logical_lan_buffer failed during recycle rc=%ld", lpar_rc);
ibmveth_remove_buffer_from_pool(adapter, adapter->rx_queue.queue_addr[adapter->rx_queue.index].correlator);
}
@@ -511,7 +511,7 @@
adapter->filter_list_dma,
mac_address);
- if(lpar_rc != H_Success) {
+ if(lpar_rc != H_SUCCESS) {
ibmveth_error_printk("h_register_logical_lan failed with %ld\n", lpar_rc);
ibmveth_error_printk("buffer TCE:0x%lx filter TCE:0x%lx rxq desc:0x%lx MAC:0x%lx\n",
adapter->buffer_list_dma,
@@ -527,7 +527,7 @@
ibmveth_error_printk("unable to request irq 0x%x, rc %d\n", netdev->irq, rc);
do {
rc = h_free_logical_lan(adapter->vdev->unit_address);
- } while (H_isLongBusy(rc) || (rc == H_Busy));
+ } while (H_IS_LONG_BUSY(rc) || (rc == H_BUSY));
ibmveth_cleanup(adapter);
return rc;
@@ -556,9 +556,9 @@
do {
lpar_rc = h_free_logical_lan(adapter->vdev->unit_address);
- } while (H_isLongBusy(lpar_rc) || (lpar_rc == H_Busy));
+ } while (H_IS_LONG_BUSY(lpar_rc) || (lpar_rc == H_BUSY));
- if(lpar_rc != H_Success)
+ if(lpar_rc != H_SUCCESS)
{
ibmveth_error_printk("h_free_logical_lan failed with %lx, continuing with close\n",
lpar_rc);
@@ -693,9 +693,9 @@
desc[4].desc,
desc[5].desc,
correlator);
- } while ((lpar_rc == H_Busy) && (retry_count--));
+ } while ((lpar_rc == H_BUSY) && (retry_count--));
- if(lpar_rc != H_Success && lpar_rc != H_Dropped) {
+ if(lpar_rc != H_SUCCESS && lpar_rc != H_DROPPED) {
int i;
ibmveth_error_printk("tx: h_send_logical_lan failed with rc=%ld\n", lpar_rc);
for(i = 0; i < 6; i++) {
@@ -786,14 +786,14 @@
/* we think we are done - reenable interrupts, then check once more to make sure we are done */
lpar_rc = h_vio_signal(adapter->vdev->unit_address, VIO_IRQ_ENABLE);
- ibmveth_assert(lpar_rc == H_Success);
+ ibmveth_assert(lpar_rc == H_SUCCESS);
netif_rx_complete(netdev);
if(ibmveth_rxq_pending_buffer(adapter) && netif_rx_reschedule(netdev, frames_processed))
{
lpar_rc = h_vio_signal(adapter->vdev->unit_address, VIO_IRQ_DISABLE);
- ibmveth_assert(lpar_rc == H_Success);
+ ibmveth_assert(lpar_rc == H_SUCCESS);
more_work = 1;
goto restart_poll;
}
@@ -813,7 +813,7 @@
if(netif_rx_schedule_prep(netdev)) {
lpar_rc = h_vio_signal(adapter->vdev->unit_address, VIO_IRQ_DISABLE);
- ibmveth_assert(lpar_rc == H_Success);
+ ibmveth_assert(lpar_rc == H_SUCCESS);
__netif_rx_schedule(netdev);
}
return IRQ_HANDLED;
@@ -835,7 +835,7 @@
IbmVethMcastEnableRecv |
IbmVethMcastDisableFiltering,
0);
- if(lpar_rc != H_Success) {
+ if(lpar_rc != H_SUCCESS) {
ibmveth_error_printk("h_multicast_ctrl rc=%ld when entering promisc mode\n", lpar_rc);
}
} else {
@@ -847,7 +847,7 @@
IbmVethMcastDisableFiltering |
IbmVethMcastClearFilterTable,
0);
- if(lpar_rc != H_Success) {
+ if(lpar_rc != H_SUCCESS) {
ibmveth_error_printk("h_multicast_ctrl rc=%ld when attempting to clear filter table\n", lpar_rc);
}
/* add the addresses to the filter table */
@@ -858,7 +858,7 @@
lpar_rc = h_multicast_ctrl(adapter->vdev->unit_address,
IbmVethMcastAddFilter,
mcast_addr);
- if(lpar_rc != H_Success) {
+ if(lpar_rc != H_SUCCESS) {
ibmveth_error_printk("h_multicast_ctrl rc=%ld when adding an entry to the filter table\n", lpar_rc);
}
}
@@ -867,7 +867,7 @@
lpar_rc = h_multicast_ctrl(adapter->vdev->unit_address,
IbmVethMcastEnableFiltering,
0);
- if(lpar_rc != H_Success) {
+ if(lpar_rc != H_SUCCESS) {
ibmveth_error_printk("h_multicast_ctrl rc=%ld when enabling filtering\n", lpar_rc);
}
}
Index: linux-2.6/drivers/scsi/ibmvscsi/rpa_vscsi.c
===================================================================
--- linux-2.6.orig/drivers/scsi/ibmvscsi/rpa_vscsi.c
+++ linux-2.6/drivers/scsi/ibmvscsi/rpa_vscsi.c
@@ -80,7 +80,7 @@
tasklet_kill(&hostdata->srp_task);
do {
rc = plpar_hcall_norets(H_FREE_CRQ, vdev->unit_address);
- } while ((rc == H_Busy) || (H_isLongBusy(rc)));
+ } while ((rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
dma_unmap_single(hostdata->dev,
queue->msg_token,
queue->size * sizeof(*queue->msgs), DMA_BIDIRECTIONAL);
@@ -230,7 +230,7 @@
rc = plpar_hcall_norets(H_REG_CRQ,
vdev->unit_address,
queue->msg_token, PAGE_SIZE);
- if (rc == H_Resource)
+ if (rc == H_RESOURCE)
/* maybe kexecing and resource is busy. try a reset */
rc = ibmvscsi_reset_crq_queue(queue,
hostdata);
@@ -269,7 +269,7 @@
req_irq_failed:
do {
rc = plpar_hcall_norets(H_FREE_CRQ, vdev->unit_address);
- } while ((rc == H_Busy) || (H_isLongBusy(rc)));
+ } while ((rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
reg_crq_failed:
dma_unmap_single(hostdata->dev,
queue->msg_token,
@@ -295,7 +295,7 @@
/* Re-enable the CRQ */
do {
rc = plpar_hcall_norets(H_ENABLE_CRQ, vdev->unit_address);
- } while ((rc == H_InProgress) || (rc == H_Busy) || (H_isLongBusy(rc)));
+ } while ((rc == H_IN_PROGRESS) || (rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
if (rc)
printk(KERN_ERR "ibmvscsi: Error %d enabling adapter\n", rc);
@@ -317,7 +317,7 @@
/* Close the CRQ */
do {
rc = plpar_hcall_norets(H_FREE_CRQ, vdev->unit_address);
- } while ((rc == H_Busy) || (H_isLongBusy(rc)));
+ } while ((rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
/* Clean out the queue */
memset(queue->msgs, 0x00, PAGE_SIZE);
Index: linux-2.6/include/asm-powerpc/hvcall.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/hvcall.h
+++ linux-2.6/include/asm-powerpc/hvcall.h
@@ -4,47 +4,54 @@
#define HVSC .long 0x44000022
-#define H_Success 0
-#define H_Busy 1 /* Hardware busy -- retry later */
-#define H_Closed 2 /* Resource closed */
-#define H_Constrained 4 /* Resource request constrained to max allowed */
-#define H_InProgress 14 /* Kind of like busy */
-#define H_Pending 17 /* returned from H_POLL_PENDING */
-#define H_Continue 18 /* Returned from H_Join on success */
-#define H_LongBusyStartRange 9900 /* Start of long busy range */
-#define H_LongBusyOrder1msec 9900 /* Long busy, hint that 1msec is a good time to retry */
-#define H_LongBusyOrder10msec 9901 /* Long busy, hint that 10msec is a good time to retry */
-#define H_LongBusyOrder100msec 9902 /* Long busy, hint that 100msec is a good time to retry */
-#define H_LongBusyOrder1sec 9903 /* Long busy, hint that 1sec is a good time to retry */
-#define H_LongBusyOrder10sec 9904 /* Long busy, hint that 10sec is a good time to retry */
-#define H_LongBusyOrder100sec 9905 /* Long busy, hint that 100sec is a good time to retry */
-#define H_LongBusyEndRange 9905 /* End of long busy range */
-#define H_Hardware -1 /* Hardware error */
-#define H_Function -2 /* Function not supported */
-#define H_Privilege -3 /* Caller not privileged */
-#define H_Parameter -4 /* Parameter invalid, out-of-range or conflicting */
-#define H_Bad_Mode -5 /* Illegal msr value */
-#define H_PTEG_Full -6 /* PTEG is full */
-#define H_Not_Found -7 /* PTE was not found" */
-#define H_Reserved_DABR -8 /* DABR address is reserved by the hypervisor on this processor" */
-#define H_NoMem -9
-#define H_Authority -10
-#define H_Permission -11
-#define H_Dropped -12
-#define H_SourceParm -13
-#define H_DestParm -14
-#define H_RemoteParm -15
-#define H_Resource -16
+#define H_SUCCESS 0
+#define H_BUSY 1 /* Hardware busy -- retry later */
+#define H_CLOSED 2 /* Resource closed */
+#define H_CONSTRAINED 4 /* Resource request constrained to max allowed */
+#define H_IN_PROGRESS 14 /* Kind of like busy */
+#define H_PENDING 17 /* returned from H_POLL_PENDING */
+#define H_CONTINUE 18 /* Returned from H_Join on success */
+#define H_LONG_BUSY_START_RANGE 9900 /* Start of long busy range */
+#define H_LONG_BUSY_ORDER_1_MSEC 9900 /* Long busy, hint that 1msec \
+ is a good time to retry */
+#define H_LONG_BUSY_ORDER_10_MSEC 9901 /* Long busy, hint that 10msec \
+ is a good time to retry */
+#define H_LONG_BUSY_ORDER_100_MSEC 9902 /* Long busy, hint that 100msec \
+ is a good time to retry */
+#define H_LONG_BUSY_ORDER_1_SEC 9903 /* Long busy, hint that 1sec \
+ is a good time to retry */
+#define H_LONG_BUSY_ORDER_10_SEC 9904 /* Long busy, hint that 10sec \
+ is a good time to retry */
+#define H_LONG_BUSY_ORDER_100_SEC 9905 /* Long busy, hint that 100sec \
+ is a good time to retry */
+#define H_LONG_BUSY_END_RANGE 9905 /* End of long busy range */
+#define H_HARDWARE -1 /* Hardware error */
+#define H_FUNCTION -2 /* Function not supported */
+#define H_PRIVILEGE -3 /* Caller not privileged */
+#define H_PARAMETER -4 /* Parameter invalid, out-of-range or conflicting */
+#define H_BAD_MODE -5 /* Illegal msr value */
+#define H_PTEG_FULL -6 /* PTEG is full */
+#define H_NOT_FOUND -7 /* PTE was not found" */
+#define H_RESERVED_DABR -8 /* DABR address is reserved by the hypervisor on this processor" */
+#define H_NO_MEM -9
+#define H_AUTHORITY -10
+#define H_PERMISSION -11
+#define H_DROPPED -12
+#define H_SOURCE_PARM -13
+#define H_DEST_PARM -14
+#define H_REMOTE_PARM -15
+#define H_RESOURCE -16
/* Long Busy is a condition that can be returned by the firmware
* when a call cannot be completed now, but the identical call
* should be retried later. This prevents calls blocking in the
- * firmware for long periods of time. Annoyingly the firmware can return
+ * firmware for long periods of time. Annoyingly the firmware can return
* a range of return codes, hinting at how long we should wait before
* retrying. If you don't care for the hint, the macro below is a good
* way to check for the long_busy return codes
*/
-#define H_isLongBusy(x) ((x >= H_LongBusyStartRange) && (x <= H_LongBusyEndRange))
+#define H_IS_LONG_BUSY(x) ((x >= H_LONG_BUSY_START_RANGE) \
+ && (x <= H_LONG_BUSY_END_RANGE))
/* Flags */
#define H_LARGE_PAGE (1UL<<(63-16))
@@ -99,25 +106,25 @@
#define H_PERFMON 0x7c
#define H_MIGRATE_DMA 0x78
#define H_REGISTER_VPA 0xDC
-#define H_CEDE 0xE0
+#define H_CEDE 0xE0
#define H_CONFER 0xE4
-#define H_PROD 0xE8
+#define H_PROD 0xE8
#define H_GET_PPP 0xEC
#define H_SET_PPP 0xF0
#define H_PURR 0xF4
-#define H_PIC 0xF8
+#define H_PIC 0xF8
#define H_REG_CRQ 0xFC
#define H_FREE_CRQ 0x100
#define H_VIO_SIGNAL 0x104
#define H_SEND_CRQ 0x108
-#define H_COPY_RDMA 0x110
+#define H_COPY_RDMA 0x110
#define H_SET_XDABR 0x134
#define H_STUFF_TCE 0x138
#define H_PUT_TCE_INDIRECT 0x13C
#define H_VTERM_PARTNER_INFO 0x150
#define H_REGISTER_VTERM 0x154
#define H_FREE_VTERM 0x158
-#define H_POLL_PENDING 0x1D8
+#define H_POLL_PENDING 0x1D8
#define H_JOIN 0x298
#define H_ENABLE_CRQ 0x2B0
@@ -152,7 +159,7 @@
*/
long plpar_hcall_8arg_2ret(unsigned long opcode,
unsigned long arg1,
- unsigned long arg2,
+ unsigned long arg2,
unsigned long arg3,
unsigned long arg4,
unsigned long arg5,
^ permalink raw reply
* Re: snd-aoa: new apple sound driver
From: Johannes Berg @ 2006-03-30 0:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc, Alastair Poole
In-Reply-To: <1143604878.3585.5.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
On Wed, 2006-03-29 at 15:01 +1100, Benjamin Herrenschmidt wrote:
> Oh, and jackd seems to be unhappy even if I tell it to ignore the
> capture channels, it's probably a problem with setting the sample
> formats, I haven't looked in detail (yet).
Yeah, that's exactly it, it is trying to set 48KHz which I don't support
yet because I'd need to do i2s cell manipulations (serial format
register etc)
$ jackd -d alsa -r 44100 -S
starts for me. Not like it actually seems to work though...
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Vitaly Bordug @ 2006-03-30 10:26 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <bed6c40abe7664da7506270a46611d00@embeddededge.com>
On Thu, 30 Mar 2006 00:05:38 -0500
Dan Malek <dan@embeddededge.com> wrote:
>
> On Mar 28, 2006, at 11:14 AM, Vitaly Bordug wrote:
>
> > Updated the documentation to include the initial description of the
> > CPM2
> > device that are used on PQII and PQIII families.
>
> I haven't followed the device tree development in detail, but when
> looking at this the only question that comes to mind is wondering
> what this really does to help me. None of the information provided
> here is variable nor configurable .... except I guess for the internal
> register base address (IMMR), which for some reason has turned
> into a variable which hasn't changed since I did the first kernel port.
> About the only thing that is variable, which is the two different bank
> addresses of the CPM memory that affects the configuration of
> the FCCs in Ethernet mode, isn't reflected here in any way.
Why do you think/guess the values below _should_ be variable? Well they could, but the target is to have the auto-config only in places it makes sense. (I currently see only PCI stuff in this relation). The dts will be compiled together with the firmware, and provide the correct information to the kernel. The dts is a board-specific thing, it is intended to present all the necessary devices to live happily without all the immr structure. In other words, what it should present, is the same logical construction uniting all the legacy (CPM on 8xx), up-to-date (CPM2 on PQ2 and PQ3) and future (QuiccEngine on 8360) boards in an easy to maintain and extensible way.
I'll elaborate of course if needed - note I am not the theoretical fanatic of this idea, but it
- makes sense,
- the new way, all that will not follow it will be obsoleted sooner or later
>
> > + brg@119f0 {
> > + device_type = "brg";
> > + model = "BRG1";
> > + reg = <119f0>;
> > + linux,phandle = <775>;
> > + };
>
> Why? We already know it's at this address offset.
Hmm? The same offset for 8xx, 82xx PQII and new QE? don't think so...
>
> > +
> > + cpmux@11b04 {
> > + device_type = "cpmux";
> > + compatible = "fcc";
> > + reg = <11b04>;
> > + };
> > +
> > + cpmux@11b08 {
> > + device_type = "cpmux";
> > + compatible = "scc";
> > + reg = <11b08>;
> > + };
>
> I don't understand the value of these either.
As far as I got the idea, on startup I'll have _only_ devicetree, in order to configure the stuff, and insert the devices properly. Hereby, I need the offsets to configure things. And I don't really want to hide those into *.h - or we'll return to #ifdef hell there. These offsets are *not* constant if we look over different PQ generations.
>
> > +
> > + scc@11a20 {
> > + device_type = "serial";
> > + compatible = "cpm_uart";
> > + model = "SCC1";
> > + reg = <11a20 100>;
> > + reg_pram = <8000 ff>;
> > + clock_setup = <0x00ffffff 0>;
> > + interrupts = <28 3>;
>
> None of this is variable. If you know you are using scc1,
> you must use certain configuration bits in the cmxscr (the
> thing you are calling cpmux). Why would you want to make
> this variable and prone to error? The driver knows, and
> there are no options. Same for the interrupts that are used.
>
Just compared in CPM, CPM2 and QE reference manuals - found no equal values. The aim is to move all that specific offsets over to BSP land in devicetree source. The logic is common, but the numbers/offsets are different, and features as well, for instance, QE UCC is much more flexible than SCC/FCC, differing technically but is really common logically.
> > + fcc@11300 {
> > + device_type = "network";
> > + compatible = "fs_enet";
> > + model = "FCC1";
> > + reg = <11300 1f>;
> > + reg_pram = <8400 ff>;
> > + address = [00 00 00 00 00 00];
>
> I'm assuming this is the MAC address, and is probably
> the only thing I see of value here.
>
> > More devices will be defined as this spec matures.
>
> I just don't understand the value of this. Will you explain
> it for me?
>
I am not a good "explainer", but AFAIR, the powerpc land is generic-code-prone. All the bsp stuff should be either dealt in the firmware, of passed as a flattened devtree and unpacked/used in one function.
Even conflicting IOPs in 8xx I am going to be configured completely within u-boot, using env or something like that. I know, the kernel should be able to deal with tuning like the upper dependless of the firmware, but there are no much such designs remaining (that are targeting to the new-generation kernel),
and all of them (I know about) are using u-boot.
> Thanks.
>
Thanks for attention to this :)
>
> -- Dan
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Vitaly Bordug @ 2006-03-30 10:37 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17451.30312.967754.699319@cargo.ozlabs.ibm.com>
On Thu, 30 Mar 2006 17:10:48 +1100
Paul Mackerras <paulus@samba.org> wrote:
> Dan Malek writes:
>
> > I haven't followed the device tree development in detail, but when
> > looking at this the only question that comes to mind is wondering
> > what this really does to help me. None of the information provided
> > here is variable nor configurable .... except I guess for the internal
> > register base address (IMMR), which for some reason has turned
> > into a variable which hasn't changed since I did the first kernel port.
> > About the only thing that is variable, which is the two different bank
> > addresses of the CPM memory that affects the configuration of
> > the FCCs in Ethernet mode, isn't reflected here in any way.
>
> I don't know much about the CPM or CPM2, so I don't know precisely why
> these bits have been put in. If the CPM2 is completely unique and is
> identical across all possible past and future implementations, then
> indeed there isn't a lot of value in putting details about it in the
> device tree. Having details in the device tree becomes useful if:
>
> * there are variants that have different collections of subdevices, or
> subdevices at different offsets, or
>
Yes. Offsets differ across the different PQ families. Collections may differ even on the same reference design, 885 for instance could have all the scc's/smc's utilized as UARTs, while on classic SMC1+SMC2, only, SCC may be used as 10M network.
> * there are common subdevices between CPM and CPM2 (or future CPM*
> devices), potentially with subtle variations in offset, method of
> enabling, etc., or
>
Yes, but this is similar with the first point... Well even cpm and cpm2 differ (different immap.h ), and we have CPM future heading for QE.
> * there are subdevices in CPM/CPM2 which match some common device
> (e.g. a 16550 uart) for which a generic driver can be used with some
> appropriate configuration.
Yep - cpm_uart and fs_enet are live examples. Both are intended to deal with serial and Ethernet stuff from the different variations of CPM. Right now they are not ideal, because they still have to remap the whole immr (say to access cpm command register) ,and such parts are still board-specific which is not good...
>
> As I say, I don't know if these points apply to CPM/CPM2 specifically.
>
> Paul.
>
>
Thank you for your comments - now I'm sure all this following the right way...
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: linux 2.4 on ml403
From: Peter Ryser @ 2006-03-30 7:48 UTC (permalink / raw)
To: jean-francois.hasson; +Cc: linuxppc-embedded
In-Reply-To: <OF281713A1.B46F6CC0-ONC1257141.0023B19E-C1257141.00241646@win-master.hsa.snecma>
Jean-Francois,
follow the instructions in the ML403 Reference Design Users Guide (pg
39). In particular, create the board support package with the Linux MLD
and use the patch_linux script in the linux sub-directory of the ML403
reference design. The patch sets bits 1 and 3 in CCR0 which is required
for ES silicon, i.e. silicon where the PPC405 has a PVR of 0x20011430.
After applying the patch the problem will be gone.
- Peter
Links:
- ML403 Web Page: http://www.xilinx.com/ml403
- ML403 Users Guide: http://www.xilinx.com/bvdocs/userguides/ug082.pdf
- ML403 reference design:
http://www.xilinx.com/products/boards/ml403/files/ml403_emb_ref_ppc_81.zip
jean-francois.hasson@hispano-suiza-sa.com wrote:
>Hi,
>
>I have been trying to run a linux 2.4 devel from the montavista site on an
>ml403 following among other things some advice from BYU website. I managed
>to have Linux start on the ml403 after downaloading it with XMD but then I
>have an error message :
>
>Xilinx Virtex-II Pro port (C) 2002 MontaVista Software, Inc.
>(source@mvista.com)
>On node 0 totalpages: 16384
>zone(0): 16384 pages.
>zone(1): 0 pages.
>zone(2): 0 pages.
>Kernel command line: console=ttyS0,9600 root=/dev/xsysace/disc0/part3 rw
>Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFE000
>Calibrating delay loop... 99.73 BogoMIPS
>Oops: kernel access of bad area, sig: 11
>NIP: 00000000 XER: 0000005E LR: 00000000 SP: C0182E50 REGS: c0182da0 TRAP:
>0400
> Not tainted
>MSR: 00001030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
>TASK = c0181020[0] 'swapper' Last syscall: 0
>last math 00000000 last altivec 00000000
>GPR00: 00000000 C0182E50 C0181020 C0181020 00000000 00000001 C0181120
>00000048
>GPR08: 00000048 00000000 00000000 00000017 24000022 0000CC60 00000000
>00000000
>GPR16: 00000000 00000000 00000000 00000000 00001032 00182ED0 00000000
>C0000000
>GPR24: C019DDB0 00000001 C01A0000 C01A0000 044AA234 00000001 00000000
>C0181020
>Call backtrace:
>00000000 C001C27C C0005F30 C00047C0 C0196064 C01943B8 C019154C
>C0002328
>Kernel panic: Aiee, killing interrupt handler!
>In interrupt handler - not syncing
> <0>Rebooting in 180 seconds..
>
>Does anyone have an idea as to what is wrong ? How could I investigate it ?
>I have turned on the xmon option while building the kernel and it indicates
>I have a kernel stack overflow. If it could help.
>
>Best regards,
>
>JF H
>
>
>
>#
> This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, please advise the sender immediately and delete this e-mail and all attached documents from your computer system. Any unauthorised disclosure, distribution or copying hereof is prohibited.
>
> Ce courriel et les documents qui y sont attaches peuvent contenir des informations confidentielles. Au cas ou vous ne seriez pas le destinataire de ce courriel, vous etes prie d'en informer l'expediteur immediatement et de le detruire ainsi que tous les documents attaches de votre systeme informatique. Toute divulgation, distribution ou copie du present courriel et des documents attaches sans autorisation prealable de son emetteur est interdite.
>#
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
>
^ permalink raw reply
* linux 2.4 on ml403
From: jean-francois.hasson @ 2006-03-30 6:34 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I have been trying to run a linux 2.4 devel from the montavista site on an
ml403 following among other things some advice from BYU website. I managed
to have Linux start on the ml403 after downaloading it with XMD but then I
have an error message :
Xilinx Virtex-II Pro port (C) 2002 MontaVista Software, Inc.
(source@mvista.com)
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,9600 root=/dev/xsysace/disc0/part3 rw
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFE000
Calibrating delay loop... 99.73 BogoMIPS
Oops: kernel access of bad area, sig: 11
NIP: 00000000 XER: 0000005E LR: 00000000 SP: C0182E50 REGS: c0182da0 TRAP:
0400
Not tainted
MSR: 00001030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c0181020[0] 'swapper' Last syscall: 0
last math 00000000 last altivec 00000000
GPR00: 00000000 C0182E50 C0181020 C0181020 00000000 00000001 C0181120
00000048
GPR08: 00000048 00000000 00000000 00000017 24000022 0000CC60 00000000
00000000
GPR16: 00000000 00000000 00000000 00000000 00001032 00182ED0 00000000
C0000000
GPR24: C019DDB0 00000001 C01A0000 C01A0000 044AA234 00000001 00000000
C0181020
Call backtrace:
00000000 C001C27C C0005F30 C00047C0 C0196064 C01943B8 C019154C
C0002328
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
<0>Rebooting in 180 seconds..
Does anyone have an idea as to what is wrong ? How could I investigate it ?
I have turned on the xmon option while building the kernel and it indicates
I have a kernel stack overflow. If it could help.
Best regards,
JF H
#
This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, please advise the sender immediately and delete this e-mail and all attached documents from your computer system. Any unauthorised disclosure, distribution or copying hereof is prohibited.
Ce courriel et les documents qui y sont attaches peuvent contenir des informations confidentielles. Au cas ou vous ne seriez pas le destinataire de ce courriel, vous etes prie d'en informer l'expediteur immediatement et de le detruire ainsi que tous les documents attaches de votre systeme informatique. Toute divulgation, distribution ou copie du present courriel et des documents attaches sans autorisation prealable de son emetteur est interdite.
#
^ permalink raw reply
* Re: Kernel for MPC Lite 5200 will not compile
From: Sylvain Munaut @ 2006-03-30 6:36 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060330003419.3FF71353A37@atlas.denx.de>
Wolfgang Denk wrote:
> In message <442B11E8.7020107@246tNt.com> you wrote:
>
>> It is ?
>>
>
> I think so.
>
The stock 2.6.15 doesn't have bestcomm.
>
>> I don't know about the 2.6-denx, but the stock 2.6.15 should work just fine.
>> What's wrong with it ? (except it misses some drivers ... it should compile
>> and boot just fine)
>>
>
> Isn't the current reengineered implementation of the BestComm code
> based on an very old Freescale version, which has known limitations
> and problems?
>
> Or has there any action resulted out of the discussion with the
> Freescale engineers, and I have missed it?
>
The microcode is updated each time I get a new copy from Freescale and the
last time I checked it was up to date is when John Rigby sent me a copy
of the
latest one.
Freescale doesn't change the software interface of the microcode tasks that
much so upgrading isn't that hard.
Regards,
Sylvain
^ 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