* [patch 2/2] Cell: Wrap master run control bit
From: Geoff Levand @ 2007-09-04 11:54 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Masato Noguchi, linuxppc-dev@ozlabs.org, Paul Mackerras
From: Masato Noguchi <Masato.Noguchi@jp.sony.com>
Add platform specific SPU run control routines.
The current spufs_run_spu() implementation uses the SPU master
run control bit (MFC_SR1[S]) to control SPE execution, but the
PS3 hypervisor does not support the use of this feature. This
change adds run control wrapper routines. The bare metal
routines use the master run control bit, and the PS3 specific
routines use the priv2 run control register.
Signed-off-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Arnd, please consider for 2.6.24.
arch/powerpc/platforms/cell/spu_manage.c | 15 +++++++++++++++
arch/powerpc/platforms/cell/spufs/backing_ops.c | 6 ++++++
arch/powerpc/platforms/cell/spufs/hw_ops.c | 10 ++++++++++
arch/powerpc/platforms/cell/spufs/run.c | 4 ++--
arch/powerpc/platforms/cell/spufs/spufs.h | 1 +
arch/powerpc/platforms/ps3/spu.c | 14 ++++++++++++++
include/asm-powerpc/spu_priv1.h | 15 +++++++++++++++
7 files changed, 63 insertions(+), 2 deletions(-)
--- a/arch/powerpc/platforms/cell/spu_manage.c
+++ b/arch/powerpc/platforms/cell/spu_manage.c
@@ -35,6 +35,7 @@
#include <asm/firmware.h>
#include <asm/prom.h>
+#include "spufs/spufs.h"
#include "interrupt.h"
struct device_node *spu_devnode(struct spu *spu)
@@ -369,6 +370,18 @@ static int of_destroy_spu(struct spu *sp
return 0;
}
+static int enable_spu_by_master_run(struct spu_context *ctx)
+{
+ ctx->ops->master_start(ctx);
+ return 0;
+}
+
+static int disable_spu_by_master_run(struct spu_context *ctx)
+{
+ ctx->ops->master_stop(ctx);
+ return 0;
+}
+
/* Hardcoded affinity idxs for qs20 */
#define QS20_SPES_PER_BE 8
static int qs20_reg_idxs[QS20_SPES_PER_BE] = { 0, 2, 4, 6, 7, 5, 3, 1 };
@@ -535,5 +548,7 @@ const struct spu_management_ops spu_mana
.enumerate_spus = of_enumerate_spus,
.create_spu = of_create_spu,
.destroy_spu = of_destroy_spu,
+ .enable_spu = enable_spu_by_master_run,
+ .disable_spu = disable_spu_by_master_run,
.init_affinity = init_affinity,
};
--- a/arch/powerpc/platforms/cell/spufs/backing_ops.c
+++ b/arch/powerpc/platforms/cell/spufs/backing_ops.c
@@ -285,6 +285,11 @@ static void spu_backing_runcntl_write(st
spin_unlock(&ctx->csa.register_lock);
}
+static void spu_backing_runcntl_stop(struct spu_context *ctx)
+{
+ spu_backing_runcntl_write(ctx, SPU_RUNCNTL_STOP);
+}
+
static void spu_backing_master_start(struct spu_context *ctx)
{
struct spu_state *csa = &ctx->csa;
@@ -381,6 +386,7 @@ struct spu_context_ops spu_backing_ops =
.get_ls = spu_backing_get_ls,
.runcntl_read = spu_backing_runcntl_read,
.runcntl_write = spu_backing_runcntl_write,
+ .runcntl_stop = spu_backing_runcntl_stop,
.master_start = spu_backing_master_start,
.master_stop = spu_backing_master_stop,
.set_mfc_query = spu_backing_set_mfc_query,
--- a/arch/powerpc/platforms/cell/spufs/hw_ops.c
+++ b/arch/powerpc/platforms/cell/spufs/hw_ops.c
@@ -220,6 +220,15 @@ static void spu_hw_runcntl_write(struct
spin_unlock_irq(&ctx->spu->register_lock);
}
+static void spu_hw_runcntl_stop(struct spu_context *ctx)
+{
+ spin_lock_irq(&ctx->spu->register_lock);
+ out_be32(&ctx->spu->problem->spu_runcntl_RW, SPU_RUNCNTL_STOP);
+ while(in_be32(&ctx->spu->problem->spu_status_R) & SPU_STATUS_RUNNING)
+ cpu_relax();
+ spin_unlock_irq(&ctx->spu->register_lock);
+}
+
static void spu_hw_master_start(struct spu_context *ctx)
{
struct spu *spu = ctx->spu;
@@ -321,6 +330,7 @@ struct spu_context_ops spu_hw_ops = {
.get_ls = spu_hw_get_ls,
.runcntl_read = spu_hw_runcntl_read,
.runcntl_write = spu_hw_runcntl_write,
+ .runcntl_stop = spu_hw_runcntl_stop,
.master_start = spu_hw_master_start,
.master_stop = spu_hw_master_stop,
.set_mfc_query = spu_hw_set_mfc_query,
--- a/arch/powerpc/platforms/cell/spufs/run.c
+++ b/arch/powerpc/platforms/cell/spufs/run.c
@@ -302,7 +302,7 @@ long spufs_run_spu(struct spu_context *c
if (mutex_lock_interruptible(&ctx->run_mutex))
return -ERESTARTSYS;
- ctx->ops->master_start(ctx);
+ spu_enable_spu(ctx);
ctx->event_return = 0;
spu_acquire(ctx);
@@ -376,7 +376,7 @@ long spufs_run_spu(struct spu_context *c
ctx->stats.libassist++;
- ctx->ops->master_stop(ctx);
+ spu_disable_spu(ctx);
ret = spu_run_fini(ctx, npc, &status);
spu_yield(ctx);
--- a/arch/powerpc/platforms/cell/spufs/spufs.h
+++ b/arch/powerpc/platforms/cell/spufs/spufs.h
@@ -170,6 +170,7 @@ struct spu_context_ops {
char*(*get_ls) (struct spu_context * ctx);
u32 (*runcntl_read) (struct spu_context * ctx);
void (*runcntl_write) (struct spu_context * ctx, u32 data);
+ void (*runcntl_stop) (struct spu_context * ctx);
void (*master_start) (struct spu_context * ctx);
void (*master_stop) (struct spu_context * ctx);
int (*set_mfc_query)(struct spu_context * ctx, u32 mask, u32 mode);
--- a/arch/powerpc/platforms/ps3/spu.c
+++ b/arch/powerpc/platforms/ps3/spu.c
@@ -28,6 +28,7 @@
#include <asm/spu_priv1.h>
#include <asm/lv1call.h>
+#include "../cell/spufs/spufs.h"
#include "platform.h"
/* spu_management_ops */
@@ -419,10 +420,23 @@ static int ps3_init_affinity(void)
return 0;
}
+static int ps3_enable_spu(struct spu_context *ctx)
+{
+ return -ENOSYS;
+}
+
+static int ps3_disable_spu(struct spu_context *ctx)
+{
+ ctx->ops->runcntl_stop(ctx);
+ return -ENOSYS;
+}
+
const struct spu_management_ops spu_management_ps3_ops = {
.enumerate_spus = ps3_enumerate_spus,
.create_spu = ps3_create_spu,
.destroy_spu = ps3_destroy_spu,
+ .enable_spu = ps3_enable_spu,
+ .disable_spu = ps3_disable_spu,
.init_affinity = ps3_init_affinity,
};
--- a/include/asm-powerpc/spu_priv1.h
+++ b/include/asm-powerpc/spu_priv1.h
@@ -24,6 +24,7 @@
#include <linux/types.h>
struct spu;
+struct spu_context;
/* access to priv1 registers */
@@ -178,6 +179,8 @@ struct spu_management_ops {
int (*enumerate_spus)(int (*fn)(void *data));
int (*create_spu)(struct spu *spu, void *data);
int (*destroy_spu)(struct spu *spu);
+ int (*enable_spu)(struct spu_context *ctx);
+ int (*disable_spu)(struct spu_context *ctx);
int (*init_affinity)(void);
};
@@ -207,6 +210,18 @@ spu_init_affinity (void)
return spu_management_ops->init_affinity();
}
+static inline int
+spu_enable_spu (struct spu_context *ctx)
+{
+ return spu_management_ops->enable_spu(ctx);
+}
+
+static inline int
+spu_disable_spu (struct spu_context *ctx)
+{
+ return spu_management_ops->disable_spu(ctx);
+}
+
/*
* The declarations folowing are put here for convenience
* and only intended to be used by the platform setup code.
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Gabriel Paubert @ 2007-09-04 11:39 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev
In-Reply-To: <46DD3CE2.4060301@genesi-usa.com>
On Tue, Sep 04, 2007 at 12:09:22PM +0100, Matt Sealey wrote:
> Hi guys,
>
> Since this is a generic PPC coding question I figured I'd send it here.
> We're
> looking to make the small effort to get ZFS-FUSE working on PPC and there is
> a need (as is implemented on Solaris) for some 'atomic' math operations to
> ease multithreading in ZFS.
>
> The Solaris PPC code drop included most of these functions for 32-bit ops on
> 32-bit PPC architectures but the 64-bit operations are not present. What I
> a not clear on is the operation of lwarx and stwcx. and if they will work if
> you are doing operations on two words at a time.
No. There is a single reservation for a single word. You need to bracket
the 64 bit operations inside a spinlock on PPC32, and then select the
number /location of spinlock(s) based on your needs, from one global
per machine to one per 64 bit variable if you find excessive contention.
If you can limit yourself with 63 bit arithmetic (63, not 64) it is
possible to use one of the bits of the 64 bit value as a spinlock.
That's sometimes the best alternative (no additional fields in
structure) and it has the finest possible granularity.
>
> There has to be something somewhere that implemented these already (gcc??)
> and if anyone knows I'd love to know..
>
> --
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
> /*
> * CDDL HEADER START
> *
> * The contents of this file are subject to the terms of the
> * Common Development and Distribution License, Version 1.0 only
> * (the "License"). You may not use this file except in compliance
> * with the License.
> *
> * You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
> * or http://www.opensolaris.org/os/licensing.
> * See the License for the specific language governing permissions
> * and limitations under the License.
> *
> * When distributing Covered Code, include this CDDL HEADER in each
> * file and include the License file at usr/src/OPENSOLARIS.LICENSE.
> * If applicable, add the following below this CDDL HEADER, with the
> * fields enclosed by brackets "[]" replaced with your own identifying
> * information: Portions Copyright [yyyy] [name of copyright owner]
> *
> * CDDL HEADER END
> */
> /*
> * Copyright (c) 2006 by Sun Microsystems, Inc. All rights reserved.
> * Use is subject to license terms.
> */
>
> #pragma ident "%Z%%M% %I% %E% SML"
>
> #include <sys/atomic.h>
>
> /*
> * Theses are the void returning variants
> */
>
> #define ATOMIC_INC(name, type) \
> void atomic_inc_##name(volatile type *target) \
> { \
> type lock; \
> \
> __asm__ __volatile__( \
> "1: lwarx %[lock],0,%[target]\n" \
> " addi %[lock],%[lock],1\n" \
> " stwcx. %[lock],0,%[target]\n" \
> " bne- 1b" \
> : [lock] "=&r" (lock) \
> : [target] "r" (target) \
> : "cc"); \
> }
>
That's wrong if lock is assigned to r0, you should use
a "b" constraint to avoid this. Same for atomic_dec below.
> ATOMIC_INC(long, unsigned long)
> ATOMIC_INC(8, uint8_t)
> ATOMIC_INC(uchar, uchar_t)
> ATOMIC_INC(16, uint16_t)
> ATOMIC_INC(ushort, ushort_t)
> ATOMIC_INC(32, uint32_t)
> ATOMIC_INC(uint, uint_t)
> ATOMIC_INC(ulong, ulong_t)
The 8 and 16 bit variants are probably wrong since they may
modify bits outside the intended bytes. Besides that they
are very likely to fail at runtime because of bad alignment.
> #define ATOMIC_ADD(name, type1, type2) \
> void atomic_add_##name(volatile type1 *target, type2 bits) \
> { \
> type1 lock; \
> \
> __asm__ __volatile__( \
> "1: lwarx %[lock],0,%[target]\n" \
> " add %[lock],%[bits],%[lock]\n" \
> " stwcx. %[lock],0,%[target]\n" \
> " bne- 1b" \
> : [lock] "=&r" (lock) \
> : [target] "r" (target), [bits] "r" (bits) \
> : "cc"); \
> }
>
> ATOMIC_ADD(8, uint8_t, int8_t)
> ATOMIC_ADD(char, uchar_t, signed char)
> ATOMIC_ADD(16, uint16_t, int16_t)
> ATOMIC_ADD(short, ushort_t, short)
> ATOMIC_ADD(32, uint32_t, int32_t)
> ATOMIC_ADD(int, uint_t, int)
> ATOMIC_ADD(long, ulong_t, long)
>
> void atomic_add_ptr(volatile void *target, ssize_t bits)
> {
> /* XXX - Implement me */
> *(caddr_t *)target += bits;
> }
>
> #if defined(_KERNEL) || defined(_INT64_TYPE)
> void atomic_add_64(volatile uint64_t *target, int64_t bits)
> {
> /* XXX - Implement me */
> *target += bits;
> }
> #endif
>
> #define ATOMIC_OR(name, type) \
> void atomic_or_##name(volatile type *target, type bits) \
> { \
> type lock; \
> \
> __asm__ __volatile__( \
> "1: lwarx %[lock],0,%[target]\n" \
> " or %[lock],%[bits],%[lock]\n" \
> " stwcx. %[lock],0,%[target]\n" \
> " bne- 1b" \
> : [lock] "=&r" (lock) \
> : [target] "r" (target), [bits] "r" (bits) \
> : "cc"); \
> }
>
> //ATOMIC_OR(long, ulong_t)
> ATOMIC_OR(8, uint8_t)
> ATOMIC_OR(uchar, uchar_t)
> ATOMIC_OR(16, uint16_t)
> ATOMIC_OR(ushort, ushort_t)
> ATOMIC_OR(32, uint32_t)
> ATOMIC_OR(uint, uint_t)
> ATOMIC_OR(ulong, ulong_t)
>
> #if defined(_KERNEL) || defined(_INT64_TYPE)
> void atomic_or_64(volatile uint64_t *target, uint64_t bits)
> {
> /* XXX - Implement me */
> *target |= bits;
> }
> #endif
>
> #define ATOMIC_AND(name, type) \
> void atomic_and_##name(volatile type *target, type bits) \
> { \
> type lock; \
> \
> __asm__ __volatile__( \
> "1: lwarx %[lock],0,%[target]\n" \
> " and %[lock],%[bits],%[lock]\n" \
> " stwcx. %[lock],0,%[target]\n" \
> " bne- 1b" \
> : [lock] "=&r" (lock) \
> : [target] "r" (target), [bits] "r" (bits) \
> : "cc"); \
> }
>
> //ATOMIC_AND(long, ulong_t)
> ATOMIC_AND(8, uint8_t)
> ATOMIC_AND(uchar, uchar_t)
> ATOMIC_AND(16, uint16_t)
> ATOMIC_AND(ushort, ushort_t)
> ATOMIC_AND(32, uint32_t)
> ATOMIC_AND(uint, uint_t)
> ATOMIC_AND(ulong, ulong_t)
>
> #if defined(_KERNEL) || defined(_INT64_TYPE)
> void atomic_and_64(volatile uint64_t *target, uint64_t bits)
> {
> /* XXX - Implement me */
> *target &= bits;
> }
> #endif
>
> /*
> * New value returning variants
> */
>
> #define ATOMIC_INC_NV(name, type) \
> type atomic_inc_##name##_nv(volatile type *target) \
> { \
> type lock; \
> \
> __asm__ __volatile__( \
> "1: lwarx %[lock],0,%[target]\n" \
> " addi %[lock],%[lock],1\n" \
> " stwcx. %[lock],0,%[target]\n" \
> " bne- 1b" \
> : [lock] "=&r" (lock) \
> : [target] "r" (target) \
> : "cc"); \
> \
> return lock; \
> }
>
> ATOMIC_INC_NV(long, unsigned long)
> ATOMIC_INC_NV(8, uint8_t)
> ATOMIC_INC_NV(uchar, uchar_t)
> ATOMIC_INC_NV(16, uint16_t)
> ATOMIC_INC_NV(ushort, ushort_t)
> ATOMIC_INC_NV(32, uint32_t)
> ATOMIC_INC_NV(uint, uint_t)
> ATOMIC_INC_NV(ulong, ulong_t)
>
> #if defined(_KERNEL) || defined(_INT64_TYPE)
> uint64_t atomic_inc_64_nv(volatile uint64_t *target)
> {
> /* XXX - Implement me */
> return (++(*target));
> }
> #endif
>
> #define ATOMIC_DEC_NV(name, type) \
> type atomic_dec_##name##_nv(volatile type *target) \
> { \
> type lock; \
> \
> __asm__ __volatile__( \
> "1: lwarx %[lock],0,%[target]\n" \
> " addi %[lock],%[lock],-1\n" \
> " stwcx. %[lock],0,%[target]\n" \
> " bne- 1b" \
> : [lock] "=&r" (lock) \
> : [target] "r" (target) \
> : "cc"); \
> \
> return lock; \
> }
>
> ATOMIC_DEC_NV(long, unsigned long)
> ATOMIC_DEC_NV(8, uint8_t)
> ATOMIC_DEC_NV(uchar, uchar_t)
> ATOMIC_DEC_NV(16, uint16_t)
> ATOMIC_DEC_NV(ushort, ushort_t)
> ATOMIC_DEC_NV(32, uint32_t)
> ATOMIC_DEC_NV(uint, uint_t)
> ATOMIC_DEC_NV(ulong, ulong_t)
>
> #if defined(_KERNEL) || defined(_INT64_TYPE)
> uint64_t atomic_dec_64_nv(volatile uint64_t *target)
> {
> /* XXX - Implement me */
> return (--(*target));
> }
> #endif
>
> #define ATOMIC_ADD_NV(name, type1, type2) \
> type1 atomic_add_##name##_nv(volatile type1 *target, type2 bits) \
> { \
> type1 lock; \
> \
> __asm__ __volatile__( \
> "1: lwarx %[lock],0,%[target]\n" \
> " add %[lock],%[bits],%[lock]\n" \
> " stwcx. %[lock],0,%[target]\n" \
> " bne- 1b" \
> : [lock] "=&r" (lock) \
> : [target] "r" (target), [bits] "r" (bits) \
> : "cc"); \
> \
> return lock; \
> }
>
> ATOMIC_ADD_NV(8, uint8_t, int8_t)
> ATOMIC_ADD_NV(char, uchar_t, signed char)
> ATOMIC_ADD_NV(16, uint16_t, int16_t)
> ATOMIC_ADD_NV(short, ushort_t, short)
> ATOMIC_ADD_NV(32, uint32_t, int32_t)
> ATOMIC_ADD_NV(int, uint_t, int)
> ATOMIC_ADD_NV(long, ulong_t, long)
>
> void *atomic_add_ptr_nv(volatile void *target, ssize_t bits)
> {
> /* XXX - Implement me */
> return (*(caddr_t *)target += bits);
> }
>
> #if defined(_KERNEL) || defined(_INT64_TYPE)
> uint64_t atomic_add_64_nv(volatile uint64_t *target, int64_t bits)
> {
> /* XXX - Implement me */
> return (*target += bits);
> }
> #endif
>
> #define ATOMIC_OR_NV(name, type) \
> type atomic_or_##name##_nv(volatile type *target, type bits) \
> { \
> type lock; \
> \
> __asm__ __volatile__( \
> "1: lwarx %[lock],0,%[target]\n" \
> " or %[lock],%[bits],%[lock]\n" \
> " stwcx. %[lock],0,%[target]\n" \
> " bne- 1b" \
> : [lock] "=&r" (lock) \
> : [target] "r" (target), [bits] "r" (bits) \
> : "cc"); \
> \
> return lock; \
> }
>
> ATOMIC_OR_NV(long, unsigned long)
> ATOMIC_OR_NV(8, uint8_t)
> ATOMIC_OR_NV(uchar, uchar_t)
> ATOMIC_OR_NV(16, uint16_t)
> ATOMIC_OR_NV(ushort, ushort_t)
> ATOMIC_OR_NV(32, uint32_t)
> ATOMIC_OR_NV(uint, uint_t)
> ATOMIC_OR_NV(ulong, ulong_t)
>
> #if defined(_KERNEL) || defined(_INT64_TYPE)
> uint64_t atomic_or_64_nv(volatile uint64_t *target, uint64_t bits)
> {
> /* XXX - Implement me */
> return (*target |= bits);
> }
> #endif
>
> #define ATOMIC_AND_NV(name, type) \
> type atomic_and_##name##_nv(volatile type *target, type bits) \
> { \
> type lock; \
> \
> __asm__ __volatile__( \
> "1: lwarx %[lock],0,%[target]\n" \
> " and %[lock],%[bits],%[lock]\n" \
> " stwcx. %[lock],0,%[target]\n" \
> " bne- 1b" \
> : [lock] "=&r" (lock) \
> : [target] "r" (target), [bits] "r" (bits) \
> : "cc"); \
> \
> return lock; \
> }
>
> ATOMIC_AND_NV(long, unsigned long)
> ATOMIC_AND_NV(8, uint8_t)
> ATOMIC_AND_NV(uchar, uchar_t)
> ATOMIC_AND_NV(16, uint16_t)
> ATOMIC_AND_NV(ushort, ushort_t)
> ATOMIC_AND_NV(32, uint32_t)
> ATOMIC_AND_NV(uint, uint_t)
> ATOMIC_AND_NV(ulong, ulong_t)
>
> #if defined(_KERNEL) || defined(_INT64_TYPE)
> uint64_t atomic_and_64_nv(volatile uint64_t *target, uint64_t bits)
> {
> /* XXX - Implement me */
> return (*target &= bits);
> }
> #endif
>
>
> /*
> * If *arg1 == arg2, set *arg1 = arg3; return old value
> */
>
> #define ATOMIC_CAS(name, type) \
> type atomic_cas_##name(volatile type *target, type arg1, type arg2) \
> { \
> type lock, old = *target; \
> \
> __asm__ __volatile__( \
> "1: lwarx %[lock],0,%[target]\n" \
> " cmpw %[lock],%[arg1]\n" \
> " bne- 2f\n" \
> " mr %[lock],%[arg2]\n" \
> " stwcx. %[lock],0,%[target]\n" \
> " bne- 1b\n" \
> "2:" \
> : [lock] "=&r" (lock) \
> : [target] "r" (target), [arg1] "r" (arg1), [arg2] "r" (arg2) \
> : "cc"); \
> \
> return old; \
> }
>
> ATOMIC_CAS(8, uint8_t)
> ATOMIC_CAS(uchar, uchar_t)
> ATOMIC_CAS(16, uint16_t)
> ATOMIC_CAS(ushort, ushort_t)
> ATOMIC_CAS(32, uint32_t)
> ATOMIC_CAS(uint, uint_t)
> ATOMIC_CAS(ulong, ulong_t)
>
> void *atomic_cas_ptr(volatile void *target, void *arg1, void *arg2)
> {
> /* XXX - Implement me */
> void *old = *(void **)target;
> if (old == arg1)
> *(void **)target = arg2;
> return (old);
> }
>
> #if defined(_KERNEL) || defined(_INT64_TYPE)
> uint64_t atomic_cas_64(volatile uint64_t *target, uint64_t arg1, uint64_t arg2)
> {
> /* XXX - Implement me */
> uint64_t old = *target;
> if (old == arg1)
> *target = arg2;
> return (old);
> }
> #endif
>
> /*
> * Swap target and return old value
> */
>
> #define ATOMIC_SWAP(name, type) \
> type atomic_swap_##name(volatile type *target, type bits) \
> { \
> type lock, old = *target; \
> \
> __asm__ __volatile__( \
> "1: lwarx %[lock],0,%[target]\n" \
> " mr %[lock],%[bits]\n" \
> " stwcx. %[lock],0,%[target]\n" \
> " bne- 1b" \
> : [lock] "=&r" (lock) \
> : [target] "r" (target), [bits] "r" (bits) \
> : "cc"); \
> \
> return old; \
> }
>
> ATOMIC_SWAP(8, uint8_t)
> ATOMIC_SWAP(uchar, uchar_t)
> ATOMIC_SWAP(16, uint16_t)
> ATOMIC_SWAP(ushort, ushort_t)
> ATOMIC_SWAP(32, uint32_t)
> ATOMIC_SWAP(uint, uint_t)
> ATOMIC_SWAP(ulong, ulong_t)
>
> void *atomic_swap_ptr(volatile void *target, void *bits)
> {
> /* XXX - Implement me */
> void *old = *(void **)target;
> *(void **)target = bits;
> return (old);
> }
>
> #if defined(_KERNEL) || defined(_INT64_TYPE)
> uint64_t atomic_swap_64(volatile uint64_t *target, uint64_t bits)
> {
> /* XXX - Implement me */
> uint64_t old = *target;
> *target = bits;
> return (old);
> }
> #endif
>
> int atomic_set_long_excl(volatile ulong_t *target, uint_t value)
> {
> /* XXX - Implement me */
> ulong_t bit = (1UL << value);
> if ((*target & bit) != 0)
> return (-1);
> *target |= bit;
> return (0);
> }
>
> int atomic_clear_long_excl(volatile ulong_t *target, uint_t value)
> {
> /* XXX - Implement me */
> ulong_t bit = (1UL << value);
> if ((*target & bit) != 0)
> return (-1);
> *target &= ~bit;
> return (0);
> }
>
> void membar_enter(void)
> {
> /* XXX - Implement me */
> }
>
> void membar_exit(void)
> {
> /* XXX - Implement me */
> }
>
> void membar_producer(void)
> {
> /* XXX - Implement me */
> }
>
> void membar_consumer(void)
> {
> /* XXX - Implement me */
> }
>
> /* Legacy kernel interfaces; they will go away (eventually). */
>
> uint8_t cas8(uint8_t *target, uint8_t arg1, uint8_t arg2)
> {
> return atomic_cas_8(target, arg1, arg2);
> }
>
> uint32_t cas32(uint32_t *target, uint32_t arg1, uint32_t arg2)
> {
> return atomic_cas_32(target, arg1, arg2);
> }
>
> uint64_t cas64(uint64_t *target, uint64_t arg1, uint64_t arg2)
> {
> return atomic_cas_64(target, arg1, arg2);
> }
>
> ulong_t caslong(ulong_t *target, ulong_t arg1, ulong_t arg2)
> {
> return atomic_cas_ulong(target, arg1, arg2);
> }
>
> void *casptr(void *target, void *arg1, void *arg2)
> {
> return atomic_cas_ptr(target, arg1, arg2);
> }
>
> void atomic_and_long(ulong_t *target, ulong_t bits)
> {
> return atomic_and_ulong(target, bits);
> }
>
> void atomic_or_long(ulong_t *target, ulong_t bits)
> {
> return atomic_or_ulong(target, bits);
> }
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Thanks and new problems
From: schardt @ 2007-09-04 12:11 UTC (permalink / raw)
To: Linux PPC Linux PPC
First, many many thanks to Grant. My VirtexII Demo Board ist running a
2.6. Linux :))
But now, i switched to a Virtex4-Board with Ethernet (Mini Module from
Avnet)
This will i used in my application, if i can handle it. :)
Linux is up and running, the ethernet is detected as eth0, link led is on
but, and thats the problem, speed negotiating das not work.
is this more a linux problem or hardware ???
Regards
Georg
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: Gerhard Pircher @ 2007-09-04 12:20 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, david
In-Reply-To: <6858c7a36ed061265937daa7b14cc5ac@kernel.crashing.org>
-------- Original-Nachricht --------
> Datum: Tue, 4 Sep 2007 00:52:02 +0200
> Von: Segher Boessenkool <segher@kernel.crashing.org>
> An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org, David Gibson <david@gibson.dropbear.id.au>
> Betreff: Re: [RFC] AmigaOne device tree source v2
> >>> Yeah, PCI is a special case for Linux. Maybe add a "pciclass,XXXX"
> >>> compatible property though, for good measure. Anything else isn't
> >>> all that useful I think.
> > Wouldn't that be the same as the class-code property?
>
> Sure, except it is a different property. If you use the "class-code"
> thing, you really should implement _all_ of the PCI binding's required
> properties. If you don't (since Linux doesn't use it anyway), it might
> still be nice to have a "compatible" property at least (since that is
> what is used for figuring out what device driver to use for this device
> node). Linux doesn't currently use that either, so you don't have to,
> but you could put it there and it would make sense, that's all.
Okay, I'll add a compatible = "pciclass,0101"; property to the node.
BTW: It looks like the Pegasos II device tree defines device_type = "spi"
for the IDE controller. Is that correct?
> If those addresses really show up in the PCI BARs (most controllers
> don't do that in legacy mode), the kernel's own PCI probing will
> see it already; if they aren't in BARs, it is a bit tricky to encode
> that correctly in the "reg" (it's perfectly well-defined, just a bit
> hard to get it right).
These addresses show up in the PCI BARs of the VIA 686B IDE controller,
even if it is configured for compatible mode.
> There is no such thing as "interrupt 14 and 15" on PCI. You can use
> the interrupt mapping recommended practice to show two interrupts
> (and their polarity, and how they are routed to the relevant interrupt
> controller) in the IDE node.
But I'll still need a quirk in the IDE driver, because it doesn't make
use of any interrupt routing information in the device tree. If so, I
can omit the whole IDE controller device node and simply rely on the
IDE driver's probe functions and the Pegasos IDE IRQ quirk.
I wonder how this issue will be handled for libata and the via-pata
driver, since IIRC this one doesn't contain the Pegasos IDE IRQ quirk.
Thanks,
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* Re: Thanks and new problems
From: Clemens Koller @ 2007-09-04 12:28 UTC (permalink / raw)
To: schardt; +Cc: Linux PPC Linux PPC
In-Reply-To: <46DD4B6A.3020401@fz-juelich.de>
schardt schrieb:
> First, many many thanks to Grant. My VirtexII Demo Board ist running a
> 2.6. Linux :))
>
> But now, i switched to a Virtex4-Board with Ethernet (Mini Module from
> Avnet)
> This will i used in my application, if i can handle it. :)
>
> Linux is up and running, the ethernet is detected as eth0, link led is on
> but, and thats the problem, speed negotiating das not work.
Check the PHY configuration (i.e. the bootstrap pins on the PHY).
And - if appropriate - read out the PHY configuration (MDIO) and see
if it's correct.
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Matt Sealey @ 2007-09-04 12:31 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: ppc-dev
In-Reply-To: <20070904113937.GA3994@iram.es>
Gabriel Paubert wrote:
> On Tue, Sep 04, 2007 at 12:09:22PM +0100, Matt Sealey wrote:
>> Hi guys,
>>
>> The Solaris PPC code drop included most of these functions for 32-bit ops on
>> 32-bit PPC architectures but the 64-bit operations are not present. What I
>> a not clear on is the operation of lwarx and stwcx. and if they will work if
>> you are doing operations on two words at a time.
>
> No. There is a single reservation for a single word.
This is what I gathered from the programming environments manual at least.
> the 64 bit operations inside a spinlock on PPC32, and then select the
> number /location of spinlock(s) based on your needs, from one global
> per machine to one per 64 bit variable if you find excessive contention.
Okay that makes sense, but it would have to be a super global big lock,
I don't think the code is there in ZFS to give every 64-bit variable it's
own dedicated spinlock (kind of an overhaul) and I'm trying to be fast..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [patch 5/6] Walnut board support
From: Josh Boyer @ 2007-09-04 12:37 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <1188741546.3772.5.camel@localhost.localdomain>
On Sun, 02 Sep 2007 08:59:06 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Mon, 2007-09-03 at 11:11 +1000, David Gibson wrote:
> > On Fri, Aug 31, 2007 at 03:04:54PM -0500, Josh Boyer wrote:
> > > Board support for the PPC405 Walnut evaluation board
> > >
> > > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> >
> > [snip]
> > > --- linux-2.6.orig/arch/powerpc/platforms/40x/Kconfig
> > > +++ linux-2.6/arch/powerpc/platforms/40x/Kconfig
> > > @@ -53,13 +53,13 @@
> > > # help
> > > # This option enables support for the IBM PPC405GPr evaluation board.
> > >
> > > -#config WALNUT
> > > -# bool "Walnut"
> > > -# depends on 40x
> > > -# default y
> > > -# select 405GP
> > > -# help
> > > -# This option enables support for the IBM PPC405GP evaluation board.
> > > +config WALNUT
> > > + bool "Walnut"
> > > + depends on 40x
> > > + default y
> > > + select 405GP
> > > + help
> > > + This option enables support for the IBM PPC405GP evaluation board.
> >
> > Surely this needs WANT_DEVICE_TREE, too.
>
> Yes, will be fixed.
Er, actually no it won't. It doesn't need to be selected here, as 40x
in arch/powerpc/platforms/Kconfig.cputype already selects
WANT_DEVICE_TREE. Same thing that ebony and bamboo do for 44x.
josh
^ permalink raw reply
* Re: [patch 3/6] Walnut DTS
From: Josh Boyer @ 2007-09-04 12:42 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <1188741584.3772.7.camel@localhost.localdomain>
On Sun, 02 Sep 2007 08:59:44 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Mon, 2007-09-03 at 11:08 +1000, David Gibson wrote:
> > On Fri, Aug 31, 2007 at 03:04:52PM -0500, Josh Boyer wrote:
> > > Device tree source file for the PPC405 Walnut evaluation board.
> > >
> > > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > >
> > > ---
> > > arch/powerpc/boot/dts/walnut.dts | 183 +++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 183 insertions(+)
> > >
> > > --- /dev/null
> > > +++ linux-2.6/arch/powerpc/boot/dts/walnut.dts
> > > @@ -0,0 +1,183 @@
> > > +/*
> > > + * Device Tree Source for IBM Walnut
> > > + *
> > > + * Copyright 2007 IBM Corp.
> > > + * Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > > + *
> > > + * 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.
> > > + */
> > > +
> > > +/ {
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + model = "ibm,walnut";
> > > + compatible = "ibm,walnut";
> > > + dcr-parent = <&/cpus/PowerPC,405GP@0>;
> > > +
> > > + cpus {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + PowerPC,405GP@0 {
> > > + device_type = "cpu";
> > > + reg = <0>;
> > > + clock-frequency = <bebc200>; /* Filled in by zImage */
> > > + timebase-frequency = <0>; /* Filled in by zImage */
> > > + i-cache-line-size = <20>;
> > > + d-cache-line-size = <20>;
> > > + i-cache-size = <4000>;
> > > + d-cache-size = <4000>;
> > > + dcr-controller;
> > > + dcr-access-method = "native";
> > > + };
> > > + };
> > > +
> > > + memory {
> > > + device_type = "memory";
> > > + reg = <0 0>; /* Filled in by zImage */
> > > + };
> > > +
> > > + UIC0: interrupt-controller {
> > > + compatible = "ibm,uic";
> > > + interrupt-controller;
> > > + cell-index = <0>;
> > > + dcr-reg = <0c0 9>;
> > > + #address-cells = <0>;
> > > + #size-cells = <0>;
> > > + #interrupt-cells = <2>;
> > > + };
> > > +
> > > + plb {
> > > + compatible = "ibm,plb3";
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + ranges;
> > > + clock-frequency = <0>; /* Filled in by zImage */
> > > +
> > > + SDRAM0: memory-controller {
> > > + compatible = "ibm,sdram-405gp";
> > > + dcr-reg = <010 2>;
> > > + };
> > > +
> > > + MAL: mcmal {
> > > + compatible = "ibm,mcmal-405gp", "ibm,mcmal";
> > > + dcr-reg = <180 62>;
> > > + num-tx-chans = <2>;
> > > + num-rx-chans = <1>;
> > > + interrupt-parent = <&UIC0>;
> > > + interrupts = <a 4 b 4 c 4 d 4 e 4>;
> > > + };
> > > +
> > > + POB0: opb {
> > > + compatible = "ibm,opb";
> >
> > Need an opb-405gp here, too.
>
> Yep.
Fixed.
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + ranges = <0 ef600000 a00000>;
> >
> > Hrm... something we ought to clarify is the interpretation of the
> > POB0_BEAR register with respect to the bridge's ranges property. For
> > 440 I think the BEAR will need to be interpreted as an OPB address,
> > rather than a PLB address, but I'm not sure if that will work here
> > with the limited ranges property you have.
>
> Ok, I'll look at this.
The BEAR will still be interpreted as a PLB address here as far as I
can see. The ranges spans the entire OPB space. Am I missing
something?
josh
^ permalink raw reply
* Re: Thanks and new problems
From: schardt @ 2007-09-04 12:48 UTC (permalink / raw)
Cc: Linux PPC Linux PPC
In-Reply-To: <46DD4F69.8060804@anagramm.de>
Ah, just found the problem in old postings
i've to use the 'a' Version of the IP-Core :)
Georg
Clemens Koller wrote:
> schardt schrieb:
>> First, many many thanks to Grant. My VirtexII Demo Board ist running a
>> 2.6. Linux :))
>>
>> But now, i switched to a Virtex4-Board with Ethernet (Mini Module from
>> Avnet)
>> This will i used in my application, if i can handle it. :)
>>
>> Linux is up and running, the ethernet is detected as eth0, link led
>> is on
>> but, and thats the problem, speed negotiating das not work.
>
> Check the PHY configuration (i.e. the bootstrap pins on the PHY).
>
> And - if appropriate - read out the PHY configuration (MDIO) and see
> if it's correct.
>
> Regards,
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
^ permalink raw reply
* RE: Ethernet weirdness on 82xx
From: Rune Torgersen @ 2007-09-04 14:06 UTC (permalink / raw)
To: Denys, linuxppc-embedded, netdev
In-Reply-To: <20070902110957.M44221@visp.net.lb>
> -----Original Message-----
> From: Denys [mailto:denys@visp.net.lb]=20
> Sent: Sunday, September 02, 2007 6:12 AM
> To: Rune Torgersen; linuxppc-embedded@ozlabs.org;=20
> netdev@vger.kernel.org
> Subject: Re: Ethernet weirdness on 82xx
>=20
> Thats normal.
> Check arp_filter sysctl :
> arp_filter - BOOLEAN
Thank you, that was it.
Did the following, and now I don't get the double resond anymore
#only respond to arps on the correct port
echo 1 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/all/arp_ignore
^ permalink raw reply
* Re: Regarding immap_86xx.h
From: Kumar Gala @ 2007-09-04 14:25 UTC (permalink / raw)
To: sivaji; +Cc: linuxppc-dev
In-Reply-To: <12472670.post@talk.nabble.com>
On Sep 4, 2007, at 1:38 AM, sivaji wrote:
>
> Hi,
> I am using 2.6.23-rc3 kernel. In this kernel immap_86xx.h
> file was
> loacted in the path: include/asm-powerpc/immap_86xx.h.
>
> This file contains only PCI and Global utility Regsiters
> Declarations. LocalBus Controller, Local Access Registers and Rapid IO
> Register Declarations are missing. Where i can find these registers
> declaration and tell the reason why the CCSRBAR Registers are
> missing in the
> file immap_86xx.h
Its most likely been removed since these structures have been
distributed to the places they are used.
- k
^ permalink raw reply
* Newbie on embedded linux on PPC: error: cannot find boot.o
From: Thomas Gerlach @ 2007-09-04 13:48 UTC (permalink / raw)
To: linuxppc-dev
hi folks,
my name is thomas trying to make embedded linux run on a powerpc, but we've got special boards here, although we use a xilinx virtex4 fpga...
as you said in the nabble-thread (see subject), i set up edk9.1 software platform settings und ran libgen to get the xparameters* files. i copied those bsp files into the kernel tree (i use your kernel linux-2.6-virtex from git.secretlabs.ca/git). after configuring the kernel settigs, i try
$ make ARCH=ppc CROSS_COMPILE=powerpc-eabi-
what i get is the following output:
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CALL scripts/checksyscalls.sh
> CHK include/linux/compile.h
> LD init/mounts.o
> powerpc-eabi-ld: cannot find boot.o
> make[1]: *** [init/mounts.o] Error 1
> make: *** [init] Error 2
so, i searched for boot.o (it exists) and even copied it into several dirs of the linux kernel tree (where i thought i would make sense), but the problem still remains.
googling results in
http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&getPagePath=17462&BV_SessionID=@@@@1197140711.1188909240@@@@&BV_EngineID=cccgaddllgmfkflcefeceihdffhdfkf.0
and this, too, doesn't take me further in solving the problem.
i hope you can help me.
many thanks in advance,
kind regards
thomas gerlach
^ permalink raw reply
* Re: ppc Floating Point support status
From: Ben Buchli @ 2007-09-04 14:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <662F11BD-C521-4914-966C-8FCB84D5F808@kernel.crashing.org>
On Wednesday 22 August 2007 15:52:09 Kumar Gala wrote:
> On Aug 22, 2007, at 1:37 PM, Ben Buchli wrote:
> > Hello everybody,
> > I was wondering what the status was on supporting floating-point
> > instructions
> > for the mpc8548. I found the suggested patch:
> > http://patchwork.ozlabs.org/linuxppc/patch?
> > order=patch&filter=none&id=9455,
> > but I'm not sure for what kernel version this is and when it will be
> > officially supported.
> >
> > Thanks a lot for your help!
> >
> > Please CC to me (bbuchli at xes-inc.com) as I haven't subscribed to
> > this list.
>
> I thing these are still up in the air based on having some sense of
> testing related to them.
>
> - k
Kumar,
thanks for getting back with me.
We're doing some early performance testing on one of our boards with an
mpc8548e. I was wondering if there's a snapshot available that we could use
and maybe do some working/testing on.
Thanks a lot.
Ben
--
--
Ben Buchli
Extreme Engineering Solutions, Inc.
608-833-1155 ext 202
^ permalink raw reply
* Re: Newbie on embedded linux on PPC: error: cannot find boot.o
From: Grant Likely @ 2007-09-04 14:47 UTC (permalink / raw)
To: Thomas Gerlach; +Cc: linuxppc-dev
In-Reply-To: <46DD6238.6030204@kip.uni-heidelberg.de>
On 9/4/07, Thomas Gerlach <gerlach@kip.uni-heidelberg.de> wrote:
> hi folks,
>
>
> my name is thomas trying to make embedded linux run on a powerpc, but we've got special boards here, although we use a xilinx virtex4 fpga...
>
> as you said in the nabble-thread (see subject), i set up edk9.1 software platform settings und ran libgen to get the xparameters* files. i copied those bsp files into the kernel tree (i use your kernel linux-2.6-virtex from git.secretlabs.ca/git). after configuring the kernel settigs, i try
>
> $ make ARCH=ppc CROSS_COMPILE=powerpc-eabi-
You should be using a Linux cross compiler, not powerpc-eabi-. The
Xilinx cross compiler will not work to compile Linux kernels.
You can build yourself a cross compiler using 'crosstool':
http://www.kegel.org/crosstool.
Alternately, you can download ELDK:
http://www.denx.de/wiki/view/DULG/ELDKAvailability
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Newbie on embedded linux on PPC: error: cannot find boot.o
From: Thomas Gerlach @ 2007-09-04 14:03 UTC (permalink / raw)
To: linuxppc-embedded
hi folks,
my name is thomas trying to make embedded linux run on a powerpc, but we've got special boards here, although we use a xilinx virtex4 fpga...
as you said in the nabble-thread (see subject), i set up edk9.1 software platform settings und ran libgen to get the xparameters* files. i copied those bsp files into the kernel tree (i use your kernel linux-2.6-virtex from git.secretlabs.ca/git). after configuring the kernel settigs, i try
$ make ARCH=ppc CROSS_COMPILE=powerpc-eabi-
what i get is the following output:
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CALL scripts/checksyscalls.sh
> CHK include/linux/compile.h
> LD init/mounts.o
> powerpc-eabi-ld: cannot find boot.o
> make[1]: *** [init/mounts.o] Error 1
> make: *** [init] Error 2
so, i searched for boot.o (it exists) and even copied it into several dirs of the linux kernel tree (where i thought i would make sense), but the problem still remains.
googling results in
http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&getPagePath=17462&BV_SessionID=@@@@1197140711.1188909240@@@@&BV_EngineID=cccgaddllgmfkflcefeceihdffhdfkf.0
and this, too, doesn't take me further in solving the problem.
i hope you can help me.
many thanks in advance,
kind regards
thomas gerlach
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Gabriel Paubert @ 2007-09-04 16:02 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev
In-Reply-To: <46DD500B.4020207@genesi-usa.com>
On Tue, Sep 04, 2007 at 01:31:07PM +0100, Matt Sealey wrote:
>
> Gabriel Paubert wrote:
> >On Tue, Sep 04, 2007 at 12:09:22PM +0100, Matt Sealey wrote:
> >>Hi guys,
> >>
> >>The Solaris PPC code drop included most of these functions for 32-bit ops
> >>on
> >>32-bit PPC architectures but the 64-bit operations are not present. What I
> >>a not clear on is the operation of lwarx and stwcx. and if they will work
> >>if
> >>you are doing operations on two words at a time.
> >
> >No. There is a single reservation for a single word.
>
> This is what I gathered from the programming environments manual at least.
Well, that's because it is fundamentally impossible to
have more than one, what would the hardware do if the second
update fails after the first has succeeded?
>
> >the 64 bit operations inside a spinlock on PPC32, and then select the
> >number /location of spinlock(s) based on your needs, from one global
> >per machine to one per 64 bit variable if you find excessive contention.
>
> Okay that makes sense, but it would have to be a super global big lock,
> I don't think the code is there in ZFS to give every 64-bit variable it's
> own dedicated spinlock (kind of an overhaul) and I'm trying to be fast..
I don't know at all the ZFS code, not any filesystem code for the
matter. But how many spinlocks would you have to take and release
per actual disk operation?
Regards,
Gabriel
^ permalink raw reply
* Re: Regarding immap_86xx.h
From: Timur Tabi @ 2007-09-04 16:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, sivaji
In-Reply-To: <706FA05F-6E3E-4A9C-9DB0-52840E178F06@kernel.crashing.org>
Kumar Gala wrote:
> Its most likely been removed since these structures have been
> distributed to the places they are used.
Not only that, but I submitted a patch to remove the PCI structure, so all
that's left is the GUTS structure.
The GUTS structure is different from other devices since it contains registers
used by a variety of devices. It's a sort of catch-all for miscellaneous
hardware configuration. That's why there's no GUTS device driver, and why I
left the structure in immap_86xx.h.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Flash on ep8248e standard motherboards
From: Bennett, Alan @ 2007-09-04 17:09 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46DD65BF.5090304@kip.uni-heidelberg.de>
Hello;
We have a custom board based on the ep8248e design from Embedded Planet
and I'm trying to use something other than codewarrior to flash u-boot
srec's=20
I'm not sure where the problem is, but I'm unable to flash the
u-boot.srec onto the Embedded Planet board (using the BDI2000), let
alone our custom board.
1. Embedded Planet ep8248E
64 MB SDRAM
64 MB Flash (x2 Am29LV256M)
2. Custom
128 MB SDRAM
128 MB Flash (X2 Spansion S29GL512N)
NOTE: CW successfully flashes both parts, but then again, it's CW.
BDI 2000 Config File:
; initialize - FLASH BR0 & OR0 (64 Mbyte)
;*******************************************
WM32 0xf0010100 0xfc001801
WM32 0xf0010104 0xfc0008c2
[FLASH]
CHIPTYPE MIRRORX16
CHIPSIZE 0x2000000
BUSWIDTH 16
I then attempt to unlock/erase/program
Check for Sanity (NOTE: using BDI 2000 PROMPT)
md 0xf0010100 2
f0010100 : 0xf8001801 - 134211583 ....
f0010104 : 0xf80008b2 - 134215502 ....
md 0xfff00000 2
fff00000 : 0x10101010 269488144 ....
fff00004 : 0x10101010 269488144 ....
All looks good. (10101010 is the existing planet core header)
TRY TO UNLOCK
unlock 0xfff00000 1000
Unlocking flash at 0xfff00000
# Invalid parameter for flash programming
TRY TO ERASE
erase 0xfff00000 UNLOCK 1000
Erasing flash at 0xfff00000
# Erasing flash memory failed
BUT
erase 0xffff0000 UNLOCK 1000
Erasing flash at 0xffff0000
Erasing flash passed
HOWEVER
mm 0xffff0000 0xdeadbeef
md 0xffff0000 1
ffff0000 : 0xffffffff
SO it doesn't seem to allow write access afterall...
Is there anyone that has a BDI 2000 config file for flashing the ep8248e
motherboard the 8MB Flash Version (64 MB flash version)=20
Thanks
-Alan
*****************************************************************
*************
CONFIDENTIAL NOTE: This e-mail and any attachments may be
confidential and protected by legal privilege. If you are not
the intended recipient, be aware that you are hereby notified
that any unauthorized review, use, disclosure, dissemination,
distribution, or copying of this communication, or any of its
contents, is strictly prohibited. If you have received this
email in error, please notify us immediately by replying to the
sender and deleting this copy and the reply from your system.
Thank you for your cooperation.
EXPORT CONTROLLED DOCUMENT
This document may contain information whose export is restricted
by the Arms Export Control Act (Title 22, U.S.C., Sec 2751 Et
Seq.) or the Export Administration Act of 1979, as amended,
(Title 50, U.S.C., App. 2401, Et. Seq.) Violations to these
export laws are subject to severe criminal penalties.
All technical data forwarded by VT Miltope to its suppliers is
EXPORT CONTROLLED. Supplier shall not disclose technical data in
any form to a Foreign Person (including foreign person employees
of Supplier), or export the technical data from the United
States without U.S. Government authority and the written
authorization of VT Miltope Contracts Department.
*****************************************************************
*************
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Matt Sealey @ 2007-09-04 17:40 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: ppc-dev
In-Reply-To: <20070904160206.GA12698@iram.es>
Gabriel Paubert wrote:
> I don't know at all the ZFS code, not any filesystem code for the
> matter. But how many spinlocks would you have to take and release
> per actual disk operation?
I have no idea, but considering the space supported by the filesystem
it's probably a hell of a lot.
It seems like we've solved it; the Solaris ppc-dev repository has an
updated atomic.c which implements a kernel mutex for 64-bit ops. I've
forwarded this on, hopefully it ISN'T a hell of a lot or this is going
to knock filesystem performance on the head for 32-bit ppc :D
Thanks for your help.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Flash on ep8248e standard motherboards
From: Alan Bennett @ 2007-09-04 18:08 UTC (permalink / raw)
To: linuxppc-embedded
Please accept my apologies for sending the last email and accept this
email address and question. without the disclaimer.
---------------------------------------------------
Hello;
We have a custom board based on the ep8248e design from Embedded
Planet and I'm trying to use something other than codewarrior to flash
u-boot srec's
I'm not sure where the problem is, but I'm unable to flash the
u-boot.srec onto the Embedded Planet board (using the BDI2000), let
alone our custom board.
1. Embedded Planet ep8248E
64 MB SDRAM
64 MB Flash (x2 Am29LV256M)
2. Custom
128 MB SDRAM
128 MB Flash (X2 Spansion S29GL512N)
NOTE: CW successfully flashes both parts, but then again, it's CW.
BDI 2000 Config File:
; initialize - FLASH BR0 & OR0 (64 Mbyte)
;*******************************************
WM32 0xf0010100 0xfc001801
WM32 0xf0010104 0xfc0008c2
[FLASH]
CHIPTYPE MIRRORX16
CHIPSIZE 0x2000000
BUSWIDTH 16
I then attempt to unlock/erase/program
Check for Sanity (NOTE: using BDI 2000 PROMPT)
md 0xf0010100 2
f0010100 : 0xf8001801 - 134211583 ....
f0010104 : 0xf80008b2 - 134215502 ....
md 0xfff00000 2
fff00000 : 0x10101010 269488144 ....
fff00004 : 0x10101010 269488144 ....
All looks good. (10101010 is the existing planet core header)
TRY TO UNLOCK
unlock 0xfff00000 1000
Unlocking flash at 0xfff00000
# Invalid parameter for flash programming
TRY TO ERASE
erase 0xfff00000 UNLOCK 1000
Erasing flash at 0xfff00000
# Erasing flash memory failed
BUT
erase 0xffff0000 UNLOCK 1000
Erasing flash at 0xffff0000
Erasing flash passed
HOWEVER
mm 0xffff0000 0xdeadbeef
md 0xffff0000 1
ffff0000 : 0xffffffff
SO it doesn't seem to allow write access afterall...
Is there anyone that has a BDI 2000 config file for flashing the
ep8248e motherboard the 8MB Flash Version (64 MB flash version)
Thanks
-Alan
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Scott Wood @ 2007-09-04 18:20 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20070904104750.GA32451@localhost.localdomain>
On Tue, Sep 04, 2007 at 02:47:50PM +0400, Anton Vorontsov wrote:
> > _and system GPIOs_ :-)
>
> Yup, firmware should set up gpios, to make initial kernel boot.
No, it should set all pins and similar setup-once type initialization
that is board-specific rather than device-specific -- there's no reason
for the kernel to need to care about that sort of thing.
> After that, kernel can and should manage GPIOs. Few examples.
>
> Say units (like USB or SPI) can work in very different modes. And
> it's okay if user want to change device mode in the runtime.
This is a special case that warrants kernel involvement. It should not
be used as justification for the bootloader leaving pins unconfigured in
the majority of cases where it does not make sense to change them at
runtime.
> Another example, power management - if some unit temporarily unused,
> to save power GPIOs should be set up differently. Say if SPI unit
> turned off (unused just now), it's wise to bring their dedicated
> GPIOs to "power saving" state (be it output0/1 or input, it
> depends).
The kernel is of course welcome to do so -- and this may be a valid
reason to attach pin information to specific device nodes, if it actually
saves a non-negligible amount of power -- but it's not a reason to force
the kernel to have to care by not setting things up in the firmware.
-Scott
^ permalink raw reply
* Re: disable interrput under ppc?
From: Scott Wood @ 2007-09-04 18:24 UTC (permalink / raw)
To: Wang, Baojun; +Cc: linuxppc-embedded
In-Reply-To: <200709041044.16525.wangbj@lzu.edu.cn>
On Tue, Sep 04, 2007 at 10:44:14AM +0800, Wang, Baojun wrote:
> hi, list
>
> How can I disable interrput like `cli' in x86?
local_irq_disable().
> I want the following code freeze the box but it doesn't, $MSR is
> altered however the box is still alive, how can I freeze the box like
> `cli' in x86? Thanks very much!
Disabling interrupts doesn't freeze the machine by itself -- it depends
on what you do afterwards, which you didn't show.
-Scott
^ permalink raw reply
* Re: disable interrput under ppc?
From: Josh Boyer @ 2007-09-04 18:37 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <20070904182433.GD18280@ld0162-tx32.am.freescale.net>
On Tue, 4 Sep 2007 13:24:33 -0500
Scott Wood <scottwood@freescale.com> wrote:
> On Tue, Sep 04, 2007 at 10:44:14AM +0800, Wang, Baojun wrote:
> > hi, list
> >
> > How can I disable interrput like `cli' in x86?
>
> local_irq_disable().
>
> > I want the following code freeze the box but it doesn't, $MSR is
> > altered however the box is still alive, how can I freeze the box like
> > `cli' in x86? Thanks very much!
>
> Disabling interrupts doesn't freeze the machine by itself -- it depends
> on what you do afterwards, which you didn't show.
If you're using a BOOKE variant, there is a way to use the DBCR0
register to set debug wait enable or something to basically hang the
CPU until something external clears that bit. But why you would want
to do that, I have no idea.
josh
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Scott Wood @ 2007-09-04 18:48 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: ppc-dev
In-Reply-To: <20070904113937.GA3994@iram.es>
On Tue, Sep 04, 2007 at 01:39:37PM +0200, Gabriel Paubert wrote:
> That's wrong if lock is assigned to r0, you should use
> a "b" constraint to avoid this. Same for atomic_dec below.
GCC should really have removed r0 from the "r" class (it isn't truly a
general-purpose register), and had a different class meaning "r"-plus-r0.
-Scott
^ permalink raw reply
* Problems with MPC8272ADS
From: Manil Gaouar @ 2007-09-04 19:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 396 bytes --]
Hi,
I am a bit newbie in this. I tried compiling Linux 2.4 using
ADS8272_deconfig from the kernel 2.6 and I have many compilation errors.
Are the deconfig files from 2.4 to 2.6 that different, or can I use the
2.6 file with little changes???
I don't understand why there is support for this board in 2.6 and not in
2.4, since Denx recommend 2.4.
Thx for your help!
[-- Attachment #2: Type: text/html, Size: 2241 bytes --]
^ 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