* [PATCH 04/16] spufs: "stataus" isnt a word.
From: arnd @ 2006-10-24 16:31 UTC (permalink / raw)
To: cbe-oss-dev, linuxppc-dev, linux-kernel, paulus; +Cc: Arnd Bergmann
In-Reply-To: <20061024163113.694643000@arndb.de>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/switch.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/switch.c
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/switch.c
@@ -102,7 +102,7 @@ static inline int check_spu_isolate(stru
* saved at this time.
*/
isolate_state = SPU_STATUS_ISOLATED_STATE |
- SPU_STATUS_ISOLATED_LOAD_STAUTUS | SPU_STATUS_ISOLATED_EXIT_STAUTUS;
+ SPU_STATUS_ISOLATED_LOAD_STATUS | SPU_STATUS_ISOLATED_EXIT_STATUS;
return (in_be32(&prob->spu_status_R) & isolate_state) ? 1 : 0;
}
@@ -1046,12 +1046,12 @@ static inline int suspend_spe(struct spu
*/
if (in_be32(&prob->spu_status_R) & SPU_STATUS_RUNNING) {
if (in_be32(&prob->spu_status_R) &
- SPU_STATUS_ISOLATED_EXIT_STAUTUS) {
+ SPU_STATUS_ISOLATED_EXIT_STATUS) {
POLL_WHILE_TRUE(in_be32(&prob->spu_status_R) &
SPU_STATUS_RUNNING);
}
if ((in_be32(&prob->spu_status_R) &
- SPU_STATUS_ISOLATED_LOAD_STAUTUS)
+ SPU_STATUS_ISOLATED_LOAD_STATUS)
|| (in_be32(&prob->spu_status_R) &
SPU_STATUS_ISOLATED_STATE)) {
out_be32(&prob->spu_runcntl_RW, SPU_RUNCNTL_STOP);
@@ -1085,7 +1085,7 @@ static inline void clear_spu_status(stru
*/
if (!(in_be32(&prob->spu_status_R) & SPU_STATUS_RUNNING)) {
if (in_be32(&prob->spu_status_R) &
- SPU_STATUS_ISOLATED_EXIT_STAUTUS) {
+ SPU_STATUS_ISOLATED_EXIT_STATUS) {
spu_mfc_sr1_set(spu,
MFC_STATE1_MASTER_RUN_CONTROL_MASK);
eieio();
@@ -1095,7 +1095,7 @@ static inline void clear_spu_status(stru
SPU_STATUS_RUNNING);
}
if ((in_be32(&prob->spu_status_R) &
- SPU_STATUS_ISOLATED_LOAD_STAUTUS)
+ SPU_STATUS_ISOLATED_LOAD_STATUS)
|| (in_be32(&prob->spu_status_R) &
SPU_STATUS_ISOLATED_STATE)) {
spu_mfc_sr1_set(spu,
Index: linux-2.6/include/asm-powerpc/spu.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/spu.h
+++ linux-2.6/include/asm-powerpc/spu.h
@@ -291,8 +291,8 @@ struct spu_problem {
#define SPU_STATUS_INVALID_INSTR 0x20
#define SPU_STATUS_INVALID_CH 0x40
#define SPU_STATUS_ISOLATED_STATE 0x80
-#define SPU_STATUS_ISOLATED_LOAD_STAUTUS 0x200
-#define SPU_STATUS_ISOLATED_EXIT_STAUTUS 0x400
+#define SPU_STATUS_ISOLATED_LOAD_STATUS 0x200
+#define SPU_STATUS_ISOLATED_EXIT_STATUS 0x400
u8 pad_0x4028_0x402c[0x4]; /* 0x4028 */
u32 spu_spe_R; /* 0x402c */
u8 pad_0x4030_0x4034[0x4]; /* 0x4030 */
--
^ permalink raw reply
* [PATCH 03/16] spufs: add support for nonschedulable contexts
From: arnd @ 2006-10-24 16:31 UTC (permalink / raw)
To: cbe-oss-dev, linuxppc-dev, linux-kernel, paulus; +Cc: Arnd Bergmann
In-Reply-To: <20061024163113.694643000@arndb.de>
From: Mark Nutter <mnutter@us.ibm.com>
This adds two new flags to spu_create:
SPU_CREATE_NONSCHED: create a context that is never moved
away from an SPE once it has started running. This flag
can only be used by tasks with the CAP_SYS_NICE capability.
SPU_CREATE_ISOLATED: create a nonschedulable context that
enters isolation mode upon first run. This requires the
SPU_CREATE_NONSCHED flag.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
Update: add psmap file.
arch/powerpc/platforms/cell/spufs/file.c | 22 ++++++++++++
arch/powerpc/platforms/cell/spufs/hw_ops.c | 5 ++
arch/powerpc/platforms/cell/spufs/inode.c | 17 +++++++++
arch/powerpc/platforms/cell/spufs/run.c | 10 ++++-
arch/powerpc/platforms/cell/spufs/spufs.h | 1
arch/powerpc/platforms/cell/spufs/switch.c | 50 +++++++++++++++++++++++++++--
include/asm-powerpc/spu.h | 5 ++
7 files changed, 103 insertions(+), 7 deletions(-)
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/file.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/file.c
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/file.c
@@ -1531,3 +1531,25 @@ struct tree_descr spufs_dir_contents[] =
{ "object-id", &spufs_object_id_ops, 0666, },
{},
};
+
+struct tree_descr spufs_dir_nosched_contents[] = {
+ { "mem", &spufs_mem_fops, 0666, },
+ { "mbox", &spufs_mbox_fops, 0444, },
+ { "ibox", &spufs_ibox_fops, 0444, },
+ { "wbox", &spufs_wbox_fops, 0222, },
+ { "mbox_stat", &spufs_mbox_stat_fops, 0444, },
+ { "ibox_stat", &spufs_ibox_stat_fops, 0444, },
+ { "wbox_stat", &spufs_wbox_stat_fops, 0444, },
+ { "signal1", &spufs_signal1_fops, 0666, },
+ { "signal2", &spufs_signal2_fops, 0666, },
+ { "signal1_type", &spufs_signal1_type, 0666, },
+ { "signal2_type", &spufs_signal2_type, 0666, },
+ { "mss", &spufs_mss_fops, 0666, },
+ { "mfc", &spufs_mfc_fops, 0666, },
+ { "cntl", &spufs_cntl_fops, 0666, },
+ { "npc", &spufs_npc_ops, 0666, },
+ { "psmap", &spufs_psmap_fops, 0666, },
+ { "phys-id", &spufs_id_ops, 0666, },
+ { "object-id", &spufs_object_id_ops, 0666, },
+ {},
+};
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/hw_ops.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/hw_ops.c
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/hw_ops.c
@@ -219,8 +219,11 @@ static char *spu_hw_get_ls(struct spu_co
static void spu_hw_runcntl_write(struct spu_context *ctx, u32 val)
{
- eieio();
+ spin_lock_irq(&ctx->spu->register_lock);
+ if (val & SPU_RUNCNTL_ISOLATE)
+ out_be64(&ctx->spu->priv2->spu_privcntl_RW, 4LL);
out_be32(&ctx->spu->problem->spu_runcntl_RW, val);
+ spin_unlock_irq(&ctx->spu->register_lock);
}
static void spu_hw_runcntl_stop(struct spu_context *ctx)
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/inode.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/inode.c
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/inode.c
@@ -258,7 +258,12 @@ spufs_mkdir(struct inode *dir, struct de
inode->i_op = &spufs_dir_inode_operations;
inode->i_fop = &simple_dir_operations;
- ret = spufs_fill_dir(dentry, spufs_dir_contents, mode, ctx);
+ if (flags & SPU_CREATE_NOSCHED)
+ ret = spufs_fill_dir(dentry, spufs_dir_nosched_contents,
+ mode, ctx);
+ else
+ ret = spufs_fill_dir(dentry, spufs_dir_contents, mode, ctx);
+
if (ret)
goto out_free_ctx;
@@ -307,6 +312,16 @@ static int spufs_create_context(struct i
{
int ret;
+ ret = -EPERM;
+ if ((flags & SPU_CREATE_NOSCHED) &&
+ !capable(CAP_SYS_NICE))
+ goto out_unlock;
+
+ ret = -EINVAL;
+ if ((flags & (SPU_CREATE_NOSCHED | SPU_CREATE_ISOLATE))
+ == SPU_CREATE_ISOLATE)
+ goto out_unlock;
+
ret = spufs_mkdir(inode, dentry, flags, mode & S_IRWXUGO);
if (ret)
goto out_unlock;
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/run.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/run.c
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/run.c
@@ -51,11 +51,17 @@ static inline int spu_stopped(struct spu
static inline int spu_run_init(struct spu_context *ctx, u32 * npc)
{
int ret;
+ unsigned long runcntl = SPU_RUNCNTL_RUNNABLE;
if ((ret = spu_acquire_runnable(ctx)) != 0)
return ret;
- ctx->ops->npc_write(ctx, *npc);
- ctx->ops->runcntl_write(ctx, SPU_RUNCNTL_RUNNABLE);
+
+ if (ctx->flags & SPU_CREATE_ISOLATE)
+ runcntl |= SPU_RUNCNTL_ISOLATE;
+ else
+ ctx->ops->npc_write(ctx, *npc);
+
+ ctx->ops->runcntl_write(ctx, runcntl);
return 0;
}
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/spufs.h
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/spufs.h
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/spufs.h
@@ -135,6 +135,7 @@ struct spufs_inode_info {
container_of(inode, struct spufs_inode_info, vfs_inode)
extern struct tree_descr spufs_dir_contents[];
+extern struct tree_descr spufs_dir_nosched_contents[];
/* system call implementation */
long spufs_run_spu(struct file *file,
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/switch.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/switch.c
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/switch.c
@@ -1916,6 +1916,51 @@ static void save_lscsa(struct spu_state
wait_spu_stopped(prev, spu); /* Step 57. */
}
+static void force_spu_isolate_exit(struct spu *spu)
+{
+ struct spu_problem __iomem *prob = spu->problem;
+ struct spu_priv2 __iomem *priv2 = spu->priv2;
+
+ /* Stop SPE execution and wait for completion. */
+ out_be32(&prob->spu_runcntl_RW, SPU_RUNCNTL_STOP);
+ iobarrier_rw();
+ POLL_WHILE_TRUE(in_be32(&prob->spu_status_R) & SPU_STATUS_RUNNING);
+
+ /* Restart SPE master runcntl. */
+ spu_mfc_sr1_set(spu, MFC_STATE1_MASTER_RUN_CONTROL_MASK);
+ iobarrier_w();
+
+ /* Initiate isolate exit request and wait for completion. */
+ out_be64(&priv2->spu_privcntl_RW, 4LL);
+ iobarrier_w();
+ out_be32(&prob->spu_runcntl_RW, 2);
+ iobarrier_rw();
+ POLL_WHILE_FALSE((in_be32(&prob->spu_status_R)
+ & SPU_STATUS_STOPPED_BY_STOP));
+
+ /* Reset load request to normal. */
+ out_be64(&priv2->spu_privcntl_RW, SPU_PRIVCNT_LOAD_REQUEST_NORMAL);
+ iobarrier_w();
+}
+
+/**
+ * stop_spu_isolate
+ * Check SPU run-control state and force isolated
+ * exit function as necessary.
+ */
+static void stop_spu_isolate(struct spu *spu)
+{
+ struct spu_problem __iomem *prob = spu->problem;
+
+ if (in_be32(&prob->spu_status_R) & SPU_STATUS_ISOLATED_STATE) {
+ /* The SPU is in isolated state; the only way
+ * to get it out is to perform an isolated
+ * exit (clean) operation.
+ */
+ force_spu_isolate_exit(spu);
+ }
+}
+
static void harvest(struct spu_state *prev, struct spu *spu)
{
/*
@@ -1928,6 +1973,7 @@ static void harvest(struct spu_state *pr
inhibit_user_access(prev, spu); /* Step 3. */
terminate_spu_app(prev, spu); /* Step 4. */
set_switch_pending(prev, spu); /* Step 5. */
+ stop_spu_isolate(spu); /* NEW. */
remove_other_spu_access(prev, spu); /* Step 6. */
suspend_mfc(prev, spu); /* Step 7. */
wait_suspend_mfc_complete(prev, spu); /* Step 8. */
@@ -2096,11 +2142,11 @@ int spu_save(struct spu_state *prev, str
acquire_spu_lock(spu); /* Step 1. */
rc = __do_spu_save(prev, spu); /* Steps 2-53. */
release_spu_lock(spu);
- if (rc) {
+ if (rc != 0 && rc != 2 && rc != 6) {
panic("%s failed on SPU[%d], rc=%d.\n",
__func__, spu->number, rc);
}
- return rc;
+ return 0;
}
EXPORT_SYMBOL_GPL(spu_save);
Index: linux-2.6/include/asm-powerpc/spu.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/spu.h
+++ linux-2.6/include/asm-powerpc/spu.h
@@ -181,8 +181,10 @@ extern struct spufs_calls {
*/
#define SPU_CREATE_EVENTS_ENABLED 0x0001
#define SPU_CREATE_GANG 0x0002
+#define SPU_CREATE_NOSCHED 0x0004
+#define SPU_CREATE_ISOLATE 0x0008
-#define SPU_CREATE_FLAG_ALL 0x0003 /* mask of all valid flags */
+#define SPU_CREATE_FLAG_ALL 0x000f /* mask of all valid flags */
#ifdef CONFIG_SPU_FS_MODULE
@@ -276,6 +278,7 @@ struct spu_problem {
u32 spu_runcntl_RW; /* 0x401c */
#define SPU_RUNCNTL_STOP 0L
#define SPU_RUNCNTL_RUNNABLE 1L
+#define SPU_RUNCNTL_ISOLATE 2L
u8 pad_0x4020_0x4024[0x4]; /* 0x4020 */
u32 spu_status_R; /* 0x4024 */
#define SPU_STOP_STATUS_SHIFT 16
--
^ permalink raw reply
* [PATCH 02/16] cell: remove unused struct spu variable
From: arnd @ 2006-10-24 16:31 UTC (permalink / raw)
To: cbe-oss-dev, linuxppc-dev, linux-kernel, paulus; +Cc: Arnd Bergmann
In-Reply-To: <20061024163113.694643000@arndb.de>
From: Geoff Levand <geoffrey.levand@am.sony.com>
Remove the mostly unused variable isrc from struct spu and a forgotten
function declaration.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
Index: linux-2.6/arch/powerpc/platforms/cell/spu_base.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spu_base.c
+++ linux-2.6/arch/powerpc/platforms/cell/spu_base.c
@@ -364,8 +364,7 @@ struct spu *spu_alloc_node(int node)
if (!list_empty(&spu_list[node])) {
spu = list_entry(spu_list[node].next, struct spu, list);
list_del_init(&spu->list);
- pr_debug("Got SPU %x %d %d\n",
- spu->isrc, spu->number, spu->node);
+ pr_debug("Got SPU %d %d\n", spu->number, spu->node);
spu_init_channels(spu);
}
mutex_unlock(&spu_mutex);
@@ -591,7 +590,6 @@ static int __init spu_map_interrupts_old
/* Add the node number */
isrc |= spu->node << IIC_IRQ_NODE_SHIFT;
- spu->isrc = isrc;
/* Now map interrupts of all 3 classes */
spu->irqs[0] = irq_create_mapping(NULL, IIC_IRQ_CLASS_0 | isrc);
@@ -733,16 +731,6 @@ struct sysdev_class spu_sysdev_class = {
set_kset_name("spu")
};
-static ssize_t spu_show_isrc(struct sys_device *sysdev, char *buf)
-{
- struct spu *spu = container_of(sysdev, struct spu, sysdev);
- return sprintf(buf, "%d\n", spu->isrc);
-
-}
-static SYSDEV_ATTR(isrc, 0400, spu_show_isrc, NULL);
-
-extern int attach_sysdev_to_node(struct sys_device *dev, int nid);
-
static int spu_create_sysdev(struct spu *spu)
{
int ret;
@@ -756,8 +744,6 @@ static int spu_create_sysdev(struct spu
return ret;
}
- if (spu->isrc != 0)
- sysdev_create_file(&spu->sysdev, &attr_isrc);
sysfs_add_device_to_node(&spu->sysdev, spu->nid);
return 0;
@@ -765,7 +751,6 @@ static int spu_create_sysdev(struct spu
static void spu_destroy_sysdev(struct spu *spu)
{
- sysdev_remove_file(&spu->sysdev, &attr_isrc);
sysfs_remove_device_from_node(&spu->sysdev, spu->nid);
sysdev_unregister(&spu->sysdev);
}
@@ -821,8 +806,8 @@ static int __init create_spu(struct devi
list_add(&spu->list, &spu_list[spu->node]);
mutex_unlock(&spu_mutex);
- pr_debug(KERN_DEBUG "Using SPE %s %02x %p %p %p %p %d\n",
- spu->name, spu->isrc, spu->local_store,
+ pr_debug(KERN_DEBUG "Using SPE %s %p %p %p %p %d\n",
+ spu->name, spu->local_store,
spu->problem, spu->priv1, spu->priv2, spu->number);
goto out;
Index: linux-2.6/include/asm-powerpc/spu.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/spu.h
+++ linux-2.6/include/asm-powerpc/spu.h
@@ -118,7 +118,6 @@ struct spu {
int number;
int nid;
unsigned int irqs[3];
- u32 isrc;
u32 node;
u64 flags;
u64 dar;
--
^ permalink raw reply
* [PATCH 01/16] spufs: wrap mfc sdr access
From: arnd @ 2006-10-24 16:31 UTC (permalink / raw)
To: cbe-oss-dev, linuxppc-dev, linux-kernel, paulus
Cc: Masato Noguchi, Arnd Bergmann
In-Reply-To: <20061024163113.694643000@arndb.de>
From: Masato Noguchi <Masato.Noguchi@jp.sony.com>
SPRN_SDR1 and the SPE's MFC SDR are hypervisor resources and
are not accessible from a logical partition. This change adds an
access wrapper.
When running on bare H/W, the spufs needs to only set the SPE's MFC SDR
to the value of the PPE's SPRN_SDR1 once at SPE initialization, so this
change renames mfc_sdr_set() to mfc_sdr_setup() and moves the
access of SPRN_SDR1 into the mmio wrapper. It also removes the now
unneeded member mfc_sdr_RW from struct spu_priv1_collapsed.
Signed-off-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
--
Index: linux-2.6/arch/powerpc/platforms/cell/spu_base.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spu_base.c
+++ linux-2.6/arch/powerpc/platforms/cell/spu_base.c
@@ -805,7 +805,7 @@ static int __init create_spu(struct devi
if (ret)
goto out_unmap;
spin_lock_init(&spu->register_lock);
- spu_mfc_sdr_set(spu, mfspr(SPRN_SDR1));
+ spu_mfc_sdr_setup(spu);
spu_mfc_sr1_set(spu, 0x33);
mutex_lock(&spu_mutex);
Index: linux-2.6/arch/powerpc/platforms/cell/spu_priv1_mmio.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spu_priv1_mmio.c
+++ linux-2.6/arch/powerpc/platforms/cell/spu_priv1_mmio.c
@@ -84,9 +84,9 @@ static void mfc_dsisr_set(struct spu *sp
out_be64(&spu->priv1->mfc_dsisr_RW, dsisr);
}
-static void mfc_sdr_set(struct spu *spu, u64 sdr)
+static void mfc_sdr_setup(struct spu *spu)
{
- out_be64(&spu->priv1->mfc_sdr_RW, sdr);
+ out_be64(&spu->priv1->mfc_sdr_RW, mfspr(SPRN_SDR1));
}
static void mfc_sr1_set(struct spu *spu, u64 sr1)
@@ -146,7 +146,7 @@ const struct spu_priv1_ops spu_priv1_mmi
.mfc_dar_get = mfc_dar_get,
.mfc_dsisr_get = mfc_dsisr_get,
.mfc_dsisr_set = mfc_dsisr_set,
- .mfc_sdr_set = mfc_sdr_set,
+ .mfc_sdr_setup = mfc_sdr_setup,
.mfc_sr1_set = mfc_sr1_set,
.mfc_sr1_get = mfc_sr1_get,
.mfc_tclass_id_set = mfc_tclass_id_set,
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/switch.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/switch.c
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/switch.c
@@ -2165,9 +2165,6 @@ static void init_priv1(struct spu_state
MFC_STATE1_PROBLEM_STATE_MASK |
MFC_STATE1_RELOCATE_MASK | MFC_STATE1_BUS_TLBIE_MASK;
- /* Set storage description. */
- csa->priv1.mfc_sdr_RW = mfspr(SPRN_SDR1);
-
/* Enable OS-specific set of interrupts. */
csa->priv1.int_mask_class0_RW = CLASS0_ENABLE_DMA_ALIGNMENT_INTR |
CLASS0_ENABLE_INVALID_DMA_COMMAND_INTR |
Index: linux-2.6/include/asm-powerpc/spu_csa.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/spu_csa.h
+++ linux-2.6/include/asm-powerpc/spu_csa.h
@@ -151,7 +151,6 @@ struct spu_priv1_collapsed {
u64 mfc_fir_chkstp_enable_RW;
u64 smf_sbi_signal_sel;
u64 smf_ato_signal_sel;
- u64 mfc_sdr_RW;
u64 tlb_index_hint_RO;
u64 tlb_index_W;
u64 tlb_vpn_RW;
Index: linux-2.6/include/asm-powerpc/spu_priv1.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/spu_priv1.h
+++ linux-2.6/include/asm-powerpc/spu_priv1.h
@@ -37,7 +37,7 @@ struct spu_priv1_ops
u64 (*mfc_dar_get) (struct spu *spu);
u64 (*mfc_dsisr_get) (struct spu *spu);
void (*mfc_dsisr_set) (struct spu *spu, u64 dsisr);
- void (*mfc_sdr_set) (struct spu *spu, u64 sdr);
+ void (*mfc_sdr_setup) (struct spu *spu);
void (*mfc_sr1_set) (struct spu *spu, u64 sr1);
u64 (*mfc_sr1_get) (struct spu *spu);
void (*mfc_tclass_id_set) (struct spu *spu, u64 tclass_id);
@@ -112,9 +112,9 @@ spu_mfc_dsisr_set (struct spu *spu, u64
}
static inline void
-spu_mfc_sdr_set (struct spu *spu, u64 sdr)
+spu_mfc_sdr_setup (struct spu *spu)
{
- spu_priv1_ops->mfc_sdr_set(spu, sdr);
+ spu_priv1_ops->mfc_sdr_setup(spu);
}
static inline void
--
^ permalink raw reply
* [PATCH 00/16] cell patches for 2.6.20
From: arnd @ 2006-10-24 16:31 UTC (permalink / raw)
To: cbe-oss-dev, linuxppc-dev, linux-kernel, paulus
These are the patches I have queued for 2.6.20 for cell,
as I got them after the merge window closed.
They apply on the current powerpc.git with the bug fixes
applied that I sent earlier.
Please review for inclusion.
Arnd <><
^ permalink raw reply
* [PATCH 1/3] spufs: fix signal2 file to report signal2
From: Arnd Bergmann @ 2006-10-24 16:27 UTC (permalink / raw)
To: Paul Mackerras
Cc: Arnd Bergmann, linuxppc-dev, Dwayne Grant Mcconnell, cbe-oss-dev,
linux-kernel
In-Reply-To: <20061024160140.452484000@arndb.de>
From: Dwayne Grant Mcconnell <decimal@us.ibm.com>
Here is a simple patch that fixes the /signal2 file to actually give
signal2 data.
Signed-off-by: Dwayne Grant Mcconnell <decimal@us.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/hw_ops.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/hw_ops.c
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/hw_ops.c
@@ -147,7 +147,7 @@ static void spu_hw_signal1_write(struct
static u32 spu_hw_signal2_read(struct spu_context *ctx)
{
- return in_be32(&ctx->spu->problem->signal_notify1);
+ return in_be32(&ctx->spu->problem->signal_notify2);
}
static void spu_hw_signal2_write(struct spu_context *ctx, u32 data)
--
^ permalink raw reply
* Re: pci_set_power_state() failure and breaking suspend
From: Scott Wood @ 2006-10-24 16:09 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel list, linuxppc-dev list, Pavel Machek, Greg KH,
linux1394-devel
In-Reply-To: <200610241400.06047.rjw@sisk.pl>
Rafael J. Wysocki wrote:
> On Tuesday, 24 October 2006 08:54, Benjamin Herrenschmidt wrote:
>>However, this raises the question of do we actually want to prevent
>>machines to suspend when they have a PCI device that don't have the PCI
>>PM capability ? I'm asking that because I can easily imagine that sort
>>of construct growing into more drivers (sounds logical if you don't
>>think) and I can even imagine somebody thinking it's a good idea to slap
>>a __must_check on pci_set_power_state() ...
>
>
> As far as the suspend to RAM is concerned, I don't know.
>
> For the suspend to disk we can ignore the error if we know that the device
> in question won't do anything like a DMA transfer into memory while we're
> creating the suspend image.
I think it should be ignored for suspend-to-RAM as well; even if a
device or two is consuming unnecessary power, it's better than not being
able to suspend at all, causing more things to consume unnecessary power.
At most, a warning should be issued so the user knows what's going on,
and can choose whether to suspend to disk instead (or choose to complain
to the device manufacturer).
-Scott
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Becky Bruce @ 2006-10-24 16:01 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <453E34FB.3030209@genesi-usa.com>
On Oct 24, 2006, at 10:44 AM, Matt Sealey wrote:
>
> Paul Mackerras wrote:
>> Matt Sealey writes:
>>
>> "PowerPC" is the name of the instruction set architecture, "POWER" is
>> the name of some specific implementations of the PowerPC architecture
>> made by a certain large multinational computer company. Unless
>> you're
>> talking about the really really old ISA that was the predecessor of
>> PowerPC, that is. :)
>
> http://www.power.org/news/articles/new_brand/#isa
>
> I'm talking about the one they consolidated from all the different
> specs
> Freescale, AMCC and IBM had about what makes a PowerPC processor.
> Since
> POWER is part of it and it's all Power.org now.. they seem to have
> changed
> the name.
>
> I don't think they have actually added anything new, that wasn't there
> before, just consolidated it. You won't seen an IBM chip with SPE
> or VLE
> unless they license the gaggle of patents Freescale have on those
> units, maybe.. but there is always a possibility. All new chips are
> being called Power (not POWER).
>
The ISA version 2.03 that you are talking about does, in fact, rename
it to "Power ISA" (big "P" little "ower") from "PowerPC ISA". This
spec is mostly a big glom of all of FSL and IBM's architecure
documentation, although there were some minor changes made and some
things were added. If you read the spec carefully (which, btw, I do
*not* recommend, as it is about 900 pages of spaghetti
documentation), you will find things in there that do not exist in
any implemented processor to date.
Cheers,
B
^ permalink raw reply
* [PATCH 3/3] cell: update defconfig
From: Arnd Bergmann @ 2006-10-24 16:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Arnd Bergmann, linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <20061024160140.452484000@arndb.de>
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/cell_defconfig
+++ linux-2.6/arch/powerpc/configs/cell_defconfig
@@ -254,6 +254,7 @@ CONFIG_SYN_COOKIES=y
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
+# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
@@ -275,7 +276,9 @@ CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
+# CONFIG_INET6_XFRM_MODE_BEET is not set
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
+# CONFIG_IPV6_SIT is not set
CONFIG_IPV6_TUNNEL=m
# CONFIG_IPV6_SUBTREES is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
@@ -406,6 +409,12 @@ CONFIG_BLK_DEV_INITRD=y
# CONFIG_ATA_OVER_ETH is not set
#
+# Misc devices
+#
+# CONFIG_SGI_IOC4 is not set
+# CONFIG_TIFM_CORE is not set
+
+#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
@@ -738,7 +747,6 @@ CONFIG_GEN_RTC=y
# TPM devices
#
# CONFIG_TCG_TPM is not set
-# CONFIG_TELCLOCK is not set
#
# I2C support
@@ -802,6 +810,7 @@ CONFIG_I2C_ALGOBIT=y
#
# Dallas's 1-wire bus
#
+# CONFIG_W1 is not set
#
# Hardware Monitoring support
@@ -810,14 +819,9 @@ CONFIG_I2C_ALGOBIT=y
# CONFIG_HWMON_VID is not set
#
-# Misc devices
-#
-
-#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
-CONFIG_VIDEO_V4L2=y
#
# Digital Video Broadcasting Devices
@@ -923,6 +927,7 @@ CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
+# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
@@ -930,6 +935,7 @@ CONFIG_FS_MBCACHE=y
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
+# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
@@ -1129,6 +1135,7 @@ CONFIG_DEBUG_FS=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_FORCED_INLINING is not set
+# CONFIG_HEADERS_CHECK is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
--
^ permalink raw reply
* [PATCH 2/3] spufs: fix another off-by-one bug in mbox_read
From: Arnd Bergmann @ 2006-10-24 16:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Arnd Bergmann, linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <20061024160140.452484000@arndb.de>
Next try, the previous one did not do what I expected.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/file.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/file.c
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/file.c
@@ -385,7 +385,7 @@ static ssize_t spufs_mbox_read(struct fi
udata = (void __user *)buf;
spu_acquire(ctx);
- for (count = 0; count <= len; count += 4, udata++) {
+ for (count = 0; (count + 4) <= len; count += 4, udata++) {
int ret;
ret = ctx->ops->mbox_read(ctx, &mbox_data);
if (ret == 0)
--
^ permalink raw reply
* [PATCH 0/3] cell fixes 2.6.19
From: Arnd Bergmann @ 2006-10-24 16:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, cbe-oss-dev, linux-kernel
A few small updates that I'd like to see get into 2.6.19.
tested against the powerpc.git merge branch.
Please apply,
Arnd <><
--
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Matt Sealey @ 2006-10-24 15:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17725.18623.768768.438157@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Matt Sealey writes:
>
> "PowerPC" is the name of the instruction set architecture, "POWER" is
> the name of some specific implementations of the PowerPC architecture
> made by a certain large multinational computer company. Unless you're
> talking about the really really old ISA that was the predecessor of
> PowerPC, that is. :)
http://www.power.org/news/articles/new_brand/#isa
I'm talking about the one they consolidated from all the different specs
Freescale, AMCC and IBM had about what makes a PowerPC processor. Since
POWER is part of it and it's all Power.org now.. they seem to have changed
the name.
I don't think they have actually added anything new, that wasn't there
before, just consolidated it. You won't seen an IBM chip with SPE or VLE
unless they license the gaggle of patents Freescale have on those
units, maybe.. but there is always a possibility. All new chips are
being called Power (not POWER).
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: MPC834x TSECs/Gianfar w/o MDIO accessible PHYs
From: Dan Malek @ 2006-10-24 14:14 UTC (permalink / raw)
To: KRONSTORFER Horst; +Cc: linuxppc-embedded
In-Reply-To: <CAB1644F1C94A24BAC68B05D0F9774635CC446@VIECLEX01.frequentis.frq>
On Oct 24, 2006, at 5:16 AM, KRONSTORFER Horst wrote:
> i therefore 'simply' removed the mdio bus and phy support and tested
> with ping over tsec0.
My experience with similar designs is you can't just
remove the knowledge of the phy from the driver. You
have to "fake" some kind of phy that causes the driver
to initialize the tsec properly.
With more people using this kind of design, it would
be nice if we could extend the phy support to more
generally allow this. For now, you will have to make
some code modifications that basically result in the
phy functions "finding" a phy and properly initializing
the data structure information to match the connection
between the tsec and the switch.
Thanks.
-- Dan
^ permalink raw reply
* Re: [RFC/PATCH 3/7] Powerpc MSI ops layer
From: Jake Moilanen @ 2006-10-24 13:44 UTC (permalink / raw)
To: michael; +Cc: Eric W. Biederman, linux-kernel, linuxppc-dev
In-Reply-To: <1161654688.2149.45.camel@localhost.localdomain>
On Tue, 2006-10-24 at 11:51 +1000, Michael Ellerman wrote:
> On Tue, 2006-10-03 at 16:54 -0500, Jake Moilanen wrote:
> > On Fri, 2006-09-29 at 07:53 +1000, Michael Ellerman wrote:
> > > Powerpc MSI ops layer.
> > >
> > > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> > > ---
> > >
> > > arch/powerpc/kernel/msi.c | 347 +++++++++++++++++++++++++++++++++++++++
> > > include/asm-powerpc/machdep.h | 6
> > > include/asm-powerpc/msi.h | 175 +++++++++++++++++++
> > > include/asm-powerpc/pci-bridge.h | 4
> > > 4 files changed, 532 insertions(+)
> > >
> > > Index: to-merge/arch/powerpc/kernel/msi.c
> > > ===================================================================
> > > --- /dev/null
> > > +++ to-merge/arch/powerpc/kernel/msi.c
> > > @@ -0,0 +1,347 @@
> > > +/*
> > > + * Copyright 2006 (C), Michael Ellerman, IBM Corporation.
> > > + *
> > > + * This program is free software; you can redistribute it and/or
> > > + * modify it under the terms of the GNU General Public License
> > > + * as published by the Free Software Foundation; either version
> > > + * 2 of the License, or (at your option) any later version.
> > > + */
> > > +
> > > +#undef DEBUG
> > > +
> > > +#include <linux/kernel.h>
> > > +#include <linux/slab.h>
> > > +#include <asm/msi.h>
> > > +#include <asm/machdep.h>
> > > +
> > > +static struct ppc_msi_ops *get_msi_ops(struct pci_dev *pdev)
> > > +{
> > > + if (ppc_md.get_msi_ops)
> > > + return ppc_md.get_msi_ops(pdev);
> > > + return NULL;
> > > +}
> > > +
> > > +/* Activated by pci=nomsi on the command line. */
> > > +static int no_msi;
> > > +
> > > +void pci_no_msi(void)
> > > +{
> > > + no_msi = 1;
> > > +}
> > > +
> > > +
> > > +/* msi_info helpers */
> > > +
> > > +static struct pci_dn *get_pdn(struct pci_dev *pdev)
> > > +{
> > > + struct device_node *dn;
> > > + struct pci_dn *pdn;
> > > +
> > > + dn = pci_device_to_OF_node(pdev);
> > > + if (!dn) {
> > > + pr_debug("get_pdn: no dn found for %s\n", pci_name(pdev));
> > > + return NULL;
> > > + }
> > > +
> > > + pdn = PCI_DN(dn);
> > > + if (!pdn) {
> > > + pr_debug("get_pdn: no pci_dn found for %s\n", pci_name(pdev));
> > > + return NULL;
> > > + }
> > > +
> > > + return pdn;
> > > +}
> > > +
> > > +static int alloc_msi_info(struct pci_dev *pdev, int num,
> > > + struct msix_entry *entries, int type)
> > > +{
> > > + struct msi_info *info;
> > > + unsigned int entries_size;
> > > + struct pci_dn *pdn;
> > > +
> > > + entries_size = sizeof(struct msix_entry) * num;
> > > +
> > > + info = kzalloc(sizeof(struct msi_info) + entries_size, GFP_KERNEL);
> >
> > Shouldn't you do a second kzalloc for info->entries, and not just add on
> > the size to the end?
>
> We could, but I don't see why it's better. It's a little sneaky to tack
> the entries on the end but I don't see a problem with it?
>
> There is a bug in there that I don't set the entries pointer before
> doing the memcpy, but I've fixed that - or is that what you meant ? :)
Yeah...I was just pointing out there was a bug. :)
^ permalink raw reply
* flash.dev for MT28F320J3
From: jaybee @ 2006-10-24 13:12 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 82 bytes --]
Hi ppl.
I am looking for "Flash.dev" file for MT28F320J3 Flash. Anybody has it???
[-- Attachment #2: Type: text/html, Size: 99 bytes --]
^ permalink raw reply
* Re: pci_set_power_state() failure and breaking suspend
From: Rafael J. Wysocki @ 2006-10-24 12:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, linux1394-devel, Linux Kernel list,
Pavel Machek, Greg KH
In-Reply-To: <1161672898.10524.596.camel@localhost.localdomain>
On Tuesday, 24 October 2006 08:54, Benjamin Herrenschmidt wrote:
> So I noticed a small regression that I think might uncover a deeper
> issue...
>
> Recently, ohci1394 grew some "proper" error handling in its suspend
> function, something that looks like:
>
> err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
> if (err)
> goto out;
>
> First, it breaks some old PowerBooks where the internal OHCI had PM
> feature exposed on PCI (the pmac specific code that follows those lines
> is enough on those machines).
>
> That can easily be fixed by removing the if (err) goto out; statement
> and having the pmac code set err to 0 in certain conditions, and I'll be
> happy to submit a patch for this.
>
> However, this raises the question of do we actually want to prevent
> machines to suspend when they have a PCI device that don't have the PCI
> PM capability ? I'm asking that because I can easily imagine that sort
> of construct growing into more drivers (sounds logical if you don't
> think) and I can even imagine somebody thinking it's a good idea to slap
> a __must_check on pci_set_power_state() ...
As far as the suspend to RAM is concerned, I don't know.
For the suspend to disk we can ignore the error if we know that the device
in question won't do anything like a DMA transfer into memory while we're
creating the suspend image.
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
^ permalink raw reply
* Re: help in block drivers
From: Fawad Lateef @ 2006-10-24 12:14 UTC (permalink / raw)
To: Rahul; +Cc: kernelnewbies, Shakthi Kannan, linuxppc-embedded
In-Reply-To: <ff9652ca0610240237j4c4c3733l15b873890bd56d42@mail.gmail.com>
On 10/24/06, Rahul <rahul.theraja@gmail.com> wrote:
>
> Can anyone tell me or send me some links that tells about the following
> functions:
> daemonize, siginitsetinv , recalc_sigpending . Though i googled, i coildnt
> get much information on them.
>
daemonize() -----> is used to make kernel thread without any
user-space resources and in the last it makes thread/process child of
init. see comments above function definition
(http://lxr.free-electrons.com/source/kernel/exit.c#373)
For understanding these sort of functions, just look for kernel_thread
documents on google and there you will find details. You can also get
information in comments above these functions definition. OR do search
for their usage in other places in kernel's code and you will get the
information related to that required function.
> Thanks in adavance
> Rahul
>
>
--
Fawad Lateef
^ permalink raw reply
* Re: pci_set_power_state() failure and breaking suspend
From: Stefan Richter @ 2006-10-24 11:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, linux1394-devel, Linux Kernel list, Greg KH
In-Reply-To: <1161678557.10524.602.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> Well, the question is wether we want to make the whole machine suspend
> fail because there is a 1394 chip that doesn't do PCI PM in or not...
>
> I can send patches "fixing" it both ways (just ignoring the result from
> pci_set_power_state in general, or just ignoring that result on Apple
> cells).
Yes, what would be the correct way to do this? And if it the latter
option, should that be implemented in ohci1394 or in pci_set_power_state?
grep says that almost nobody checks the return code of
pci_set_power_state. But e.g. usb/core/hcd-pci.c does...
(Side note: The sole function that ohci1394's suspend and resume hooks
fulfill right now in mainline is to change power consumption of the
chip. The IEEE 1394 stack as a whole does not survive suspend + resume
yet. A still incomplete solution is in linux1394-2.6.git.)
--
Stefan Richter
-=====-=-==- =-=- ==---
http://arcgraph.de/sr/
^ permalink raw reply
* Re: Re: JFFS2 on Lite5200
From: Andrea Galbusera @ 2006-10-24 10:15 UTC (permalink / raw)
To: avolkov, dwmw2, dedekind; +Cc: linux-mtd, linuxppc-embedded
Hi all!
First let me thank you all for your quick and kind help... I was out for
a few days so I take the time to reply only now.
On Tue, 2006-10-17 at 17:20 +0400, Andrey Volkov wrote:
> OMG, again same question,
Sorry Andrey for my too superficial search in the ml archive... Anyway
it seems this issue is somehow still open. ;-)
At moment I'm going with Andrey's patch (it works!) but I'd like to
understand better and maybe to help solving the problem. I see that
patching include/asm-ppc/io.h may not be the right way...
I'm pretty new to kernel hacking/developing so I got confused by your
discussion about the right place to patch things.
So a few questions arise. Do we need to change the physmap driver? Is
this somehow dependent on the target platform. If so can we put some
changes for Lite5200 only?
On Tue, 2006-10-17 at 17:54 +0400, Andrey Volkov wrote:
> There are two modes of operation for JFFS2 scan. Either it can use the
> MTD device's read() function to read from the flash into memory and
> scan
> from there, or -- IF the flash can be accessed as if it were normal
> memory -- it can use the point() method and skip the read() call by
> using a pointer directly into the flash.
>
> In your case, the flash cannot be accessed directly as if it were
> normal
> memory. So your map driver probably shouldn't be allowing point() to
> succeed.
>
> Having said that, I'm not entirely sure we have the code set up so
> that
> 'simple' map drivers _can_ prevent point(). We may need to fix that.
Looking at David's explanation about mapping driver... What does exacly
mean preventing point()/unpoint() to succeed? As a simple MTD _user_
(never digged inside the code) I don't see any hook to these functions
in drivers/mtd/maps/physmap.c so no easy way to set them to NULL.
--
Andrea Galbusera <andrea.galbusera@teamware.it>
^ permalink raw reply
* Re: help in block drivers
From: Rahul @ 2006-10-24 9:37 UTC (permalink / raw)
To: Fawad Lateef; +Cc: kernelnewbies, Shakthi Kannan, linuxppc-embedded
In-Reply-To: <ff9652ca0610220202w4b0d831bu202ccff8ed941f2d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]
On 10/22/06, Rahul <rahul.theraja@gmail.com> wrote:
>
>
>
> On 10/20/06, Fawad Lateef <fawadlateef@gmail.com> wrote:
> >
> > Hello Rahul,
> >
> > First of all please don't do top-posting rather do bottom-posting. For
> > more information search google.
>
>
> oh sorry for that
>
> On 10/19/06, Rahul Theraja <rahul.theraja@gmail.com > wrote:
> > > Hello Shakthi Kannan,
> > >
> > > Thanks for the reply .
> > >
> > >
> > > > > driver. I could not understand why the "sbd_request " is called
> > even
> > > though
> > > > > i have given only one read call from user space file.
> > > >
> > > > Block device I/O transfer is done in blocks.
> > > >
> > > > > And also in the driver, in the function sbd_request() how does
> > the
> > > driver
> > > > > get the parameters like sector, current_nr_sectors and buffer.
> > > >
> > > > VFS <-> SCSI <-> Block device?
> > > >
> >
> > I think its VFS<->Buffer-Cache<->Block-Device and if drive is mounted
> > then VFS<->FS<->Buffer-Cache<->Block-Device
> >
> > > > > i could move
> > > > > furhter fastly.
> > > >
> > > > Fastly? IMHO, learning kernel development involves lot of patience.
> > > >
> > > > SK
> > >
> > >
> > > Is it necessary to use kernel_thread() in block drivers.
> > In drivers/block
> > > loop.c i could see kernel_thread() being used but in floopy.c it is
> > not
> > > used. When is this kernel_thread() function is supposed to be used
> > ? In the
> > > sbd_device also the kernel_thread() is not used.
> > >
> >
> > First in kernel-2.6.x its better to use kthread_*() rather than
> > kernel_thread if threading is needed.
> >
> > Threading isn't necessary in any device until unless you need it. For
> > example if your driver is emulating a device or performing IO directly
> > then you don't need it, but if your driver is sending request to a
> > device which generates interrupts after completing IO and you want to
> > do some extra work after getting IO completion interrupt then you must
> > use thread. As threads work in process-context, hence can do sleep and
> > lengthy processing but interrupt-context shouldn't sleep or nor do
> > long processing.
> >
> > For getting more understanding about different contexts like process,
> > interrupt, softirqs contexts do search google.
> >
> > > Anyone please kindly clarify my doubts.
> > >
> >
> > I hope you doubts are not clear.
>
>
Can anyone tell me or send me some links that tells about the following
functions:
daemonize, siginitsetinv , recalc_sigpending . Though i googled, i coildnt
get much information on them.
Thanks in adavance
Rahul
thank you very much for all the help
>
> > Thanks in Advance
> > >
> > > -Rahul
> > >
> >
> > --
> > Fawad Lateef
> >
>
>
[-- Attachment #2: Type: text/html, Size: 4317 bytes --]
^ permalink raw reply
* MPC834x TSECs/Gianfar w/o MDIO accessible PHYs
From: KRONSTORFER Horst @ 2006-10-24 9:16 UTC (permalink / raw)
To: linuxppc-embedded
hi!
in our design we use an mpc8343 with the 2 tsecs connected to a
zarlink zl50411 eth switch in mii mode. the 2 ports of the switch
are running in phy mode (reverse mii) w/o mdio. we're currently
running kernel 2.6.17.13.
i therefore 'simply' removed the mdio bus and phy support and tested
with ping over tsec0. result: i can see arp requests which are some-
what malformed (dest mac addr is not bcast, source ip addr is incorrect,
etc ...) btw: i used the same approach in u-boot and it works fine.
i then checked the content of the sk_buff handed over to gfar_start_xmit
which is correct (mac addrs, ip addrs, ...)
i'm currently out of ideas, any kind of help is appreciated!
thanks
-h
^ permalink raw reply
* Re: pci_set_power_state() failure and breaking suspend
From: Stefan Richter @ 2006-10-24 8:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, linux1394-devel, Linux Kernel list, Greg KH
In-Reply-To: <1161675611.10524.598.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
>> Recently, ohci1394 grew some "proper" error handling in its suspend
>> function, something that looks like:
>>
>> err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
>> if (err)
>> goto out;
...
> First, it breaks some old PowerBooks where the internal OHCI has no PM
> feature exposed on PCI....
Just out of curiosity: Are these HCs actual PCI hardware or are they
glued onto an extra PCI interface? Does the startup message of ohci1394
log OHCI 1.1 or 1.0 compliance for them? Probably the latter; OHCI 1.1
was released in January 2000.
OHCI 1.1 says "PCI based 1394 Open Host Controllers /should/ implement
PCI Power Management, and implementations that support PCI Power
Management /shall/ exhibit behavior consistent with this Annex."
(Emphasis mine.) I.e. a compliant HC does either not support power
management at all or supports it including the pci_set_power_state()
triggered state transitions.
OHCI 1.00 does not have a power management specification. It points to
the PCI Local Bus Specification Revision 2.1 though (which I don't have).
We are still working on full power management support by ohci1394 and
upper IEEE 1394 layers, so I am glad to get feedback and patches.
--
Stefan Richter
-=====-=-==- =-=- ==---
http://arcgraph.de/sr/
^ permalink raw reply
* Re: pci_set_power_state() failure and breaking suspend
From: Benjamin Herrenschmidt @ 2006-10-24 8:29 UTC (permalink / raw)
To: Stefan Richter
Cc: linuxppc-dev list, linux1394-devel, Linux Kernel list, Greg KH
In-Reply-To: <453DCB17.6050304@s5r6.in-berlin.de>
> Just out of curiosity: Are these HCs actual PCI hardware or are they
> glued onto an extra PCI interface? Does the startup message of ohci1394
> log OHCI 1.1 or 1.0 compliance for them? Probably the latter; OHCI 1.1
> was released in January 2000.
I don't have one at hand right now but I suspect it's 1.1. I'll ask
paulus tomorrow. They are cells inside an Apple ASIC but on a PCI bus
(on-chip PCI bus).
> OHCI 1.1 says "PCI based 1394 Open Host Controllers /should/ implement
> PCI Power Management, and implementations that support PCI Power
> Management /shall/ exhibit behavior consistent with this Annex."
> (Emphasis mine.) I.e. a compliant HC does either not support power
> management at all or supports it including the pci_set_power_state()
> triggered state transitions.
Well, the old Apple ones support power management but not the PCI PM
states. However, there are separate magic bits in the Apple ASIC that
can be used to toggle the clocks on/off (which is that the ppc specific
bits do basically, along as turning off power on the bus).
> OHCI 1.00 does not have a power management specification. It points to
> the PCI Local Bus Specification Revision 2.1 though (which I don't have).
>
> We are still working on full power management support by ohci1394 and
> upper IEEE 1394 layers, so I am glad to get feedback and patches.
Well, the question is wether we want to make the whole machine suspend
fail because there is a 1394 chip that doesn't do PCI PM in or not...
I can send patches "fixing" it both ways (just ignoring the result from
pci_set_power_state in general, or just ignoring that result on Apple
cells).
Ben.
^ permalink raw reply
* Re: pci_set_power_state() failure and breaking suspend
From: Benjamin Herrenschmidt @ 2006-10-24 7:40 UTC (permalink / raw)
To: linux1394-devel; +Cc: linuxppc-dev list, Linux Kernel list, Greg KH
In-Reply-To: <1161672898.10524.596.camel@localhost.localdomain>
On Tue, 2006-10-24 at 16:54 +1000, Benjamin Herrenschmidt wrote:
> So I noticed a small regression that I think might uncover a deeper
> issue...
>
> Recently, ohci1394 grew some "proper" error handling in its suspend
> function, something that looks like:
>
> err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
> if (err)
> goto out;
>
> First, it breaks some old PowerBooks where the internal OHCI had PM
> feature exposed on PCI (the pmac specific code that follows those lines
> is enough on those machines).
If I could type, the above would have read...
First, it breaks some old PowerBooks where the internal OHCI has no PM
feature exposed on PCI....
Ben.
^ permalink raw reply
* RE: ARCH=powerpc: IRQ numbers change mysteriously
From: Li Yang-r58472 @ 2006-10-24 7:20 UTC (permalink / raw)
To: Fredrik Roubert, linuxppc-embedded
In-Reply-To: <20061023164116.GC15953@igloo.df.lth.se>
The irq number on powerpc ARCH is now a virtual number. This change was
introduced by Ben's irq mapping change in early 2.6.18-rc.
- Leo
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org] On
Behalf Of
> Fredrik Roubert
> Sent: Tuesday, October 24, 2006 12:41 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: ARCH=3Dpowerpc: IRQ numbers change mysteriously
>=20
> Hi!
>=20
> On my MPC8439 based board, running Linux 2.6.18 with ARCH=3Dpowerpc, =
the
> IRQ's for the I2C behave in a for me mysterious way.
>=20
> In my DTS file, I have the following:
>=20
>=20
> i2c@3000 {
> device_type =3D "i2c";
> compatible =3D "fsl-i2c";
> reg =3D <3000 100>;
> interrupts =3D <e 8>;
> interrupt-parent =3D <&/soc8349@ff400000/pic@700>;
> dfsrr;
> };
>=20
> i2c@3100 {
> device_type =3D "i2c";
> compatible =3D "fsl-i2c";
> reg =3D <3000 100>;
> interrupts =3D <f 8>;
> interrupt-parent =3D <&/soc8349@ff400000/pic@700>;
> dfsrr;
> };
>=20
>=20
> But when I boot the system and cat /proc/interrupts, the output says:
>=20
>=20
> 18: 61 IPIC Level i2c-mpc
> 19: 0 IPIC Level i2c-mpc
>=20
>=20
> This doesn't make sense to me. Why are the IRQ numbers changed? They
are
> still adjacent, so it seems to be some logic to the change. Does
anyone
> know what this is?
>=20
> Cheers // Fredrik Roubert
>=20
> --
> Barco Medical Imaging | +32 56 233549
> http://www.barco.com/medical/ | fredrik.roubert@barco.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ 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