* Re: [patch 3/6] Walnut DTS
From: David Gibson @ 2007-09-07 1:07 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070905113317.630ee687@weaponx.rchland.ibm.com>
On Wed, Sep 05, 2007 at 11:33:17AM -0500, Josh Boyer wrote:
> Updated DTS below
>
> Device tree source file for the PPC405 Walnut evaluation board.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [patch v2] Cell: Wrap master run control bit
From: Geoff Levand @ 2007-09-07 1:26 UTC (permalink / raw)
To: jk; +Cc: Masato Noguchi, linuxppc-dev@ozlabs.org, Paul Mackerras,
Arnd Bergmann
In-Reply-To: <200709050042.13926.arnd@arndb.de>
Subject: Cell: Wrap master run control bit
From: Masato Noguchi <Masato.Noguchi@jp.sony.com>
Add platform specific SPU run control routines to the spufs. The current
spufs 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 the run control wrapper routies spu_enable_spu() and
spu_disable_spu(). The bare metal routines use the master run control
bit, and the PS3 specific routines use the priv2 run control register.
An outstanding enhancement for the PS3 would be to add a guard to check
for incorrect access to the spu problem state when the spu context is
disabled. This check could be implemented with a flag added to the spu
context that would inhibit mapping problem state pages, and a routine
to unmap spu problem state pages. When the spu is enabled with
ps3_enable_spu() the flag would be set allowing pages to be mapped,
and when the spu is disabled with ps3_disable_spu() the flag would be
cleared and mapped problem state pages would be unmapped.
Signed-off-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
v2:
o Added comments about unmapping PS pages when disabled.
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 | 27 ++++++++++++++++++++++++
include/asm-powerpc/spu_priv1.h | 15 +++++++++++++
7 files changed, 76 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,36 @@ static int ps3_init_affinity(void)
return 0;
}
+/**
+ * ps3_enable_spu - Type of spe to create.
+ *
+ * An outstanding enhancement for the PS3 would be to add a guard to check
+ * for incorrect access to the spu problem state when the spu context is
+ * disabled. This check could be implemented with a flag added to the spu
+ * context that would inhibit mapping problem state pages, and a routine
+ * to unmap spu problem state pages. When the spu is enabled with
+ * ps3_enable_spu() the flag would be set allowing pages to be mapped,
+ * and when the spu is disabled with ps3_disable_spu() the flag would be
+ * cleared and the mapped problem state pages would be unmapped.
+ */
+
+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: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Timur Tabi @ 2007-09-07 1:28 UTC (permalink / raw)
To: Scott Wood, Anton Vorontsov, linuxppc-dev, Timur Tabi
In-Reply-To: <20070907011553.GO26079@localhost.localdomain>
David Gibson wrote:
> Firmwares are, more often than not, crap, and that's unlikely to
> change. For a lot of things, having the kernel or bootwrapper cope as
> a special case with a handful of crap firmwares which don't set things
> up properly isn't actually any easier than having it set them up
> itself, always.
Similarly, firmware is very often unlikely to be updated. So we need to
support situations where we use old firmware with new kernels. The cuImage
support is a classic example of this. Moving code from kernel to firmware
just because some people think it belongs in the firmware is usually impractical.
If we added code to U-Boot today to configure the par_io pins, it would
probably still be years before we could safely remove that code from the kernel.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [patch 6/6] Walnut zImage wrapper
From: David Gibson @ 2007-09-07 1:22 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070905113604.746ee01c@weaponx.rchland.ibm.com>
On Wed, Sep 05, 2007 at 11:36:04AM -0500, Josh Boyer wrote:
> Updated patch below
>
> Add zImage wrapper for walnut board
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 2/2] Cell: Wrap master run control bit
From: Geoff Levand @ 2007-09-07 1:31 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Masato Noguchi, linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <200709050042.13926.arnd@arndb.de>
Arnd Bergmann wrote:
> On Tuesday 04 September 2007, Geoff Levand wrote:
>>
>> 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>
>
> Hmm, ok. Since I don't think we'll get to do the right solution
> (unmapping the ps registers on the ps3) that soon, doing this
> patch is at least better than the current situation where we
> end up with an oops every time we leave spu_run.
>
> It would probably be good to mention the remaining problem
> with the current approach in the changelog and as a comment
> in the ps3 specific functions.
Ok, I did that.
>> @@ -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);
>> };
>
> Also, I think you should make the return type of the callback
> 'void' since the result is not used anywhere.
Noguchi-san was hesitant to do this. I also thought lets leave it
as is until we consider the unmapping support, as maybe a return
value might make sense. Jeremy, if you think it better to return
void, please make the update.
-Geoff
^ permalink raw reply
* RE: Re: PCI target implementation on AMCC PPC CPUs
From: Leonid @ 2007-09-07 2:13 UTC (permalink / raw)
To: sdeven.lee, David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <46E0B178.00C522.05513@m5-81.163.com>
Hi:
You want to say PPC440GP cannot be PCI slave without this =
non-transparent bridge because as David said its "interrupt pin register =
hardwired to zero" or there other reasons?=20
I'm trying to use PPC440ep(or epx) and from its datasheet I don't see =
anything about this zero hardwiring. Does it mean "vanilla" PPC440ep =
will work?
And what did you use for PCI Host?
Also, is your code available somwhere?
Thanks,
Leonid.
-----Original Message-----
From: sdeven.lee [mailto:sdeven.lee@163.com]=20
Sent: Thursday, September 06, 2007 7:04 PM
To: David Hawkins
Cc: Leonid; linuxppc-embedded
Subject: Re: Re: PCI target implementation on AMCC PPC CPUs
David Hawkins,=C4=FA=BA=C3=A3=A1
I have been finished an application using AMCC PPC440GP as PCI =
target(slave) in the last 2 month.I use a non-transparent bridge(AMCC =
PCI6466) to make the device a target(slave) like david has said.
=3D=3D=3D=3D=3D=3D=3D 2007-09-07 04:26:01 =
=C4=FA=D4=DA=C0=B4=D0=C5=D6=D0=D0=B4=B5=C0=A3=BA=3D=3D=3D=3D=3D=3D=3D
>Hi Leonid,
>
>In case they are not in the document:
>
>There are several fundamental problems with the AMCC 440EP acting as a=20
>PCI target/slave;
>
>1. As a PCI target, there is only one way to generate
> an interrupt to a host; you basically toggle the
> interrupt pin. This makes it tricky to develop a
> host-to-slave communications protocol, eg. its
> hard to use the single interrupt to indicate various
> interrupt states, eg. target-to-host buffer has
> data versus host-to-target buffer has been emptied.
> Ideally AMCC should have implemented mailboxes and/or
> doorbell registers like any other sane PCI target
> device (eg. some the Freescale processors, or any of
> the PLX technologies chips).
>
>2. Look in the data sheet and see if you can figure out
> how the host processor can generate an interrupt to
> the PowerPC core ... oops, you can't. That kind of
> makes it difficult to work with doesn't it.
>
> A work around would be to have the host write to the
> GPIO register and wire a GPIO pin back to an external
> interrupt pin. Then you would not be able to use any
> other GPIO pin in that GPIO register since there is
> no way to arbitrate host access versus PowerPC core
> access.
>
>This was the other reason I ditched the AMCC part in favor of the=20
>Freescale part.
>
>If you are looking at other parts, make sure you look in the PCI=20
>configuration space of the processor reference manual. Many processors=20
>have the interrupt pin register hardwired to zero, i.e., they can not=20
>be used as target devices, only hosts. In that case you'd have to add=20
>an intel 21555 non-transparent bridge to make the device a target.
>
>Cheers,
>Dave
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =
=3D =3D
=09
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=D6=C2
=C0=F1=A3=A1
=20
=20
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1sdeven.lee
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1sdeven.lee@163.com
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12007-09-07
^ permalink raw reply
* Re: Re: PCI target implementation on AMCC PPC CPUs
From: sdeven.lee @ 2007-09-07 2:03 UTC (permalink / raw)
To: David Hawkins; +Cc: Leonid, linuxppc-embedded
RGF2aWQgSGF3a2lucyzE+rrDo6ENCg0KCUkgaGF2ZSBiZWVuIGZpbmlzaGVkIGFuIGFwcGxpY2F0
aW9uIHVzaW5nIEFNQ0MgUFBDNDQwR1AgYXMgUENJIHRhcmdldChzbGF2ZSkgaW4gdGhlIGxhc3Qg
MiBtb250aC5JIHVzZSBhIG5vbi10cmFuc3BhcmVudCBicmlkZ2UoQU1DQyBQQ0k2NDY2KSB0byBt
YWtlIHRoZSBkZXZpY2UgYSB0YXJnZXQoc2xhdmUpIGxpa2UgZGF2aWQgaGFzIHNhaWQuDQoNCj09
PT09PT0gMjAwNy0wOS0wNyAwNDoyNjowMSDE+tTawLTQxdbQ0LS1wKO6PT09PT09PQ0KDQo+SGkg
TGVvbmlkLA0KPg0KPkluIGNhc2UgdGhleSBhcmUgbm90IGluIHRoZSBkb2N1bWVudDoNCj4NCj5U
aGVyZSBhcmUgc2V2ZXJhbCBmdW5kYW1lbnRhbCBwcm9ibGVtcyB3aXRoIHRoZSBBTUNDIDQ0MEVQ
DQo+YWN0aW5nIGFzIGEgUENJIHRhcmdldC9zbGF2ZTsNCj4NCj4xLiBBcyBhIFBDSSB0YXJnZXQs
IHRoZXJlIGlzIG9ubHkgb25lIHdheSB0byBnZW5lcmF0ZQ0KPiAgICBhbiBpbnRlcnJ1cHQgdG8g
YSBob3N0OyB5b3UgYmFzaWNhbGx5IHRvZ2dsZSB0aGUNCj4gICAgaW50ZXJydXB0IHBpbi4gVGhp
cyBtYWtlcyBpdCB0cmlja3kgdG8gZGV2ZWxvcCBhDQo+ICAgIGhvc3QtdG8tc2xhdmUgY29tbXVu
aWNhdGlvbnMgcHJvdG9jb2wsIGVnLiBpdHMNCj4gICAgaGFyZCB0byB1c2UgdGhlIHNpbmdsZSBp
bnRlcnJ1cHQgdG8gaW5kaWNhdGUgdmFyaW91cw0KPiAgICBpbnRlcnJ1cHQgc3RhdGVzLCBlZy4g
dGFyZ2V0LXRvLWhvc3QgYnVmZmVyIGhhcw0KPiAgICBkYXRhIHZlcnN1cyBob3N0LXRvLXRhcmdl
dCBidWZmZXIgaGFzIGJlZW4gZW1wdGllZC4NCj4gICAgSWRlYWxseSBBTUNDIHNob3VsZCBoYXZl
IGltcGxlbWVudGVkIG1haWxib3hlcyBhbmQvb3INCj4gICAgZG9vcmJlbGwgcmVnaXN0ZXJzIGxp
a2UgYW55IG90aGVyIHNhbmUgUENJIHRhcmdldA0KPiAgICBkZXZpY2UgKGVnLiBzb21lIHRoZSBG
cmVlc2NhbGUgcHJvY2Vzc29ycywgb3IgYW55IG9mDQo+ICAgIHRoZSBQTFggdGVjaG5vbG9naWVz
IGNoaXBzKS4NCj4NCj4yLiBMb29rIGluIHRoZSBkYXRhIHNoZWV0IGFuZCBzZWUgaWYgeW91IGNh
biBmaWd1cmUgb3V0DQo+ICAgIGhvdyB0aGUgaG9zdCBwcm9jZXNzb3IgY2FuIGdlbmVyYXRlIGFu
IGludGVycnVwdCB0bw0KPiAgICB0aGUgUG93ZXJQQyBjb3JlIC4uLiBvb3BzLCB5b3UgY2FuJ3Qu
IFRoYXQga2luZCBvZg0KPiAgICBtYWtlcyBpdCBkaWZmaWN1bHQgdG8gd29yayB3aXRoIGRvZXNu
J3QgaXQuDQo+DQo+ICAgIEEgd29yayBhcm91bmQgd291bGQgYmUgdG8gaGF2ZSB0aGUgaG9zdCB3
cml0ZSB0byB0aGUNCj4gICAgR1BJTyByZWdpc3RlciBhbmQgd2lyZSBhIEdQSU8gcGluIGJhY2sg
dG8gYW4gZXh0ZXJuYWwNCj4gICAgaW50ZXJydXB0IHBpbi4gVGhlbiB5b3Ugd291bGQgbm90IGJl
IGFibGUgdG8gdXNlIGFueQ0KPiAgICBvdGhlciBHUElPIHBpbiBpbiB0aGF0IEdQSU8gcmVnaXN0
ZXIgc2luY2UgdGhlcmUgaXMNCj4gICAgbm8gd2F5IHRvIGFyYml0cmF0ZSBob3N0IGFjY2VzcyB2
ZXJzdXMgUG93ZXJQQyBjb3JlDQo+ICAgIGFjY2Vzcy4NCj4NCj5UaGlzIHdhcyB0aGUgb3RoZXIg
cmVhc29uIEkgZGl0Y2hlZCB0aGUgQU1DQyBwYXJ0IGluDQo+ZmF2b3Igb2YgdGhlIEZyZWVzY2Fs
ZSBwYXJ0Lg0KPg0KPklmIHlvdSBhcmUgbG9va2luZyBhdCBvdGhlciBwYXJ0cywgbWFrZSBzdXJl
IHlvdSBsb29rDQo+aW4gdGhlIFBDSSBjb25maWd1cmF0aW9uIHNwYWNlIG9mIHRoZSBwcm9jZXNz
b3IgcmVmZXJlbmNlDQo+bWFudWFsLiBNYW55IHByb2Nlc3NvcnMgaGF2ZSB0aGUgaW50ZXJydXB0
IHBpbiByZWdpc3Rlcg0KPmhhcmR3aXJlZCB0byB6ZXJvLCBpLmUuLCB0aGV5IGNhbiBub3QgYmUg
dXNlZCBhcyB0YXJnZXQNCj5kZXZpY2VzLCBvbmx5IGhvc3RzLiBJbiB0aGF0IGNhc2UgeW91J2Qg
aGF2ZSB0byBhZGQgYW4NCj5pbnRlbCAyMTU1NSBub24tdHJhbnNwYXJlbnQgYnJpZGdlIHRvIG1h
a2UgdGhlIGRldmljZQ0KPmEgdGFyZ2V0Lg0KPg0KPkNoZWVycywNCj5EYXZlDQo+DQo+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5MaW51eHBwYy1lbWJl
ZGRlZCBtYWlsaW5nIGxpc3QNCj5MaW51eHBwYy1lbWJlZGRlZEBvemxhYnMub3JnDQo+aHR0cHM6
Ly9vemxhYnMub3JnL21haWxtYW4vbGlzdGluZm8vbGludXhwcGMtZW1iZWRkZWQNCg0KPSA9ID0g
PSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9DQoJCQkNCg0KoaGhoaGhoaGhoaGhoaGh
odbCDQrA8aOhDQogDQoJCQkJIA0KoaGhoaGhoaGhoaGhoaGhoXNkZXZlbi5sZWUNCqGhoaGhoaGh
oaGhoaGhoaFzZGV2ZW4ubGVlQDE2My5jb20NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNy0wOS0w
Nw0KDQo=
^ permalink raw reply
* Re: PCI target implementation on AMCC PPC CPUs
From: David Hawkins @ 2007-09-07 2:34 UTC (permalink / raw)
To: Leonid; +Cc: linuxppc-embedded
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C022418FF@ehost011-3.exch011.intermedia.net>
Hi guys,
> You want to say PPC440GP cannot be PCI slave without
> this non-transparent bridge because as David said
> its "interrupt pin register hardwired to zero" or
> there other reasons? I'm trying to use
> PPC440ep(or epx) and from its datasheet I don't
> see anything about this zero hardwiring.
> Does it mean "vanilla" PPC440ep will work?
Look in the user manual p562
https://www.amcc.com/MyAMCC/retrieveDocument/PowerPC/440GP/PPC440GP_UM2002_v1_11.pdf
The processor can generate INTA#.
> I have been finished an application using AMCC
> PPC440GP as PCI target(slave) in the last 2 month.
> I use a non-transparent bridge(AMCC PCI6466) to
> make the device a target(slave) like david has said.
However in this case, the bridge was not required
to make the processor target-capable. Most likely
the board required a local PCI bus, and so the
non-transparent bridge is used to hide the board
PCI devices from the other PCI host.
In this type of design the processor is acting
a *host* on the target board. When a host wants
to interrupt the target, it asserts an interrupt
in the bridge, and that interrupt asserts an
interrupt input on the processor.
When the target processor wants to interrupt the
host it writes to a register in the bridge and
the bridge interrupt the host using its INTA#.
In both cases the bridge is the target and the
processors are both hosts.
:)
Dave
^ permalink raw reply
* Re: RE: Re: PCI target implementation on AMCC PPC CPUs
From: sdeven.lee @ 2007-09-07 2:52 UTC (permalink / raw)
To: Leonid, David Hawkins; +Cc: linuxppc-embedded
TGVvbmlkLMT6usOjoQ0KDQoJU29ycnksIEkgd2FzIHdyb25nLCBub3QgQU1DQyBQQ0k2NDY2LCBi
dXQgUExYIFBDSTY0NjYgbm9uLXRyYW5zcGFyZW50IGJyaWRnZS4NCg0KCUkgdXNlIHRoZSBub24t
dHJhbnNwYXJlbnQgYnJpZGdlIGp1c3QgZm9yIHNvbWUgc3BlY2lhbCBwdXJwb3NlLiBJbiB0aGlz
IGNhc2UsIHRoZSBob3N0IENQVSBjYW4ndCAgYWNjZXNzIHRoZSBtZW1vcnkgdmlhIHRoZSBicmlk
Z2UuIEkga25vdyBQUEM0NDBHUCBjYW4gcnVuIGluIGFnZW50IG1vZGUganVzdCBsaWtlIHlvdXIg
YXBwbGljYXRpb24uIEJ1dCBpdCBuZWVkcyBzcGVjaWFsIGNvbm5lY3Rpb24gb2YgdGhlIHBpbnMu
ICANCg0KPT09PT09PSAyMDA3LTA5LTA3IDEwOjEzOjMyIMT61NrAtNDF1tDQtLXAo7o9PT09PT09
DQoNCj5IaToNCj4NCj5Zb3Ugd2FudCB0byBzYXkgIFBQQzQ0MEdQIGNhbm5vdCBiZSBQQ0kgc2xh
dmUgd2l0aG91dCB0aGlzIG5vbi10cmFuc3BhcmVudCBicmlkZ2UgYmVjYXVzZSBhcyBEYXZpZCBz
YWlkIGl0cyAiaW50ZXJydXB0IHBpbiByZWdpc3RlciBoYXJkd2lyZWQgdG8gemVybyIgb3IgdGhl
cmUgb3RoZXIgcmVhc29ucz8gDQo+SSdtIHRyeWluZyB0byB1c2UgUFBDNDQwZXAob3IgZXB4KSBh
bmQgZnJvbSBpdHMgZGF0YXNoZWV0IEkgZG9uJ3Qgc2VlIGFueXRoaW5nIGFib3V0IHRoaXMgemVy
byBoYXJkd2lyaW5nLiBEb2VzIGl0IG1lYW4gInZhbmlsbGEiIFBQQzQ0MGVwIHdpbGwgd29yaz8N
Cj4NCj5BbmQgd2hhdCBkaWQgeW91IHVzZSBmb3IgUENJIEhvc3Q/DQo+DQo+QWxzbywgaXMgeW91
ciBjb2RlIGF2YWlsYWJsZSBzb213aGVyZT8NCj4NCj5UaGFua3MsDQo+DQo+TGVvbmlkLg0KPi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogc2RldmVuLmxlZSBbbWFpbHRvOnNkZXZl
bi5sZWVAMTYzLmNvbV0gDQo+U2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAwNiwgMjAwNyA3OjA0
IFBNDQo+VG86IERhdmlkIEhhd2tpbnMNCj5DYzogTGVvbmlkOyBsaW51eHBwYy1lbWJlZGRlZA0K
PlN1YmplY3Q6IFJlOiBSZTogUENJIHRhcmdldCBpbXBsZW1lbnRhdGlvbiBvbiBBTUNDIFBQQyBD
UFVzDQo+DQo+RGF2aWQgSGF3a2lucyzE+rrDo6ENCj4NCj4JSSBoYXZlIGJlZW4gZmluaXNoZWQg
YW4gYXBwbGljYXRpb24gdXNpbmcgQU1DQyBQUEM0NDBHUCBhcyBQQ0kgdGFyZ2V0KHNsYXZlKSBp
biB0aGUgbGFzdCAyIG1vbnRoLkkgdXNlIGEgbm9uLXRyYW5zcGFyZW50IGJyaWRnZShBTUNDIFBD
STY0NjYpIHRvIG1ha2UgdGhlIGRldmljZSBhIHRhcmdldChzbGF2ZSkgbGlrZSBkYXZpZCBoYXMg
c2FpZC4NCj4NCj49PT09PT09IDIwMDctMDktMDcgMDQ6MjY6MDEgxPrU2sC00MXW0NC0tcCjuj09
PT09PT0NCj4NCj4+SGkgTGVvbmlkLA0KPj4NCj4+SW4gY2FzZSB0aGV5IGFyZSBub3QgaW4gdGhl
IGRvY3VtZW50Og0KPj4NCj4+VGhlcmUgYXJlIHNldmVyYWwgZnVuZGFtZW50YWwgcHJvYmxlbXMg
d2l0aCB0aGUgQU1DQyA0NDBFUCBhY3RpbmcgYXMgYSANCj4+UENJIHRhcmdldC9zbGF2ZTsNCj4+
DQo+PjEuIEFzIGEgUENJIHRhcmdldCwgdGhlcmUgaXMgb25seSBvbmUgd2F5IHRvIGdlbmVyYXRl
DQo+PiAgICBhbiBpbnRlcnJ1cHQgdG8gYSBob3N0OyB5b3UgYmFzaWNhbGx5IHRvZ2dsZSB0aGUN
Cj4+ICAgIGludGVycnVwdCBwaW4uIFRoaXMgbWFrZXMgaXQgdHJpY2t5IHRvIGRldmVsb3AgYQ0K
Pj4gICAgaG9zdC10by1zbGF2ZSBjb21tdW5pY2F0aW9ucyBwcm90b2NvbCwgZWcuIGl0cw0KPj4g
ICAgaGFyZCB0byB1c2UgdGhlIHNpbmdsZSBpbnRlcnJ1cHQgdG8gaW5kaWNhdGUgdmFyaW91cw0K
Pj4gICAgaW50ZXJydXB0IHN0YXRlcywgZWcuIHRhcmdldC10by1ob3N0IGJ1ZmZlciBoYXMNCj4+
ICAgIGRhdGEgdmVyc3VzIGhvc3QtdG8tdGFyZ2V0IGJ1ZmZlciBoYXMgYmVlbiBlbXB0aWVkLg0K
Pj4gICAgSWRlYWxseSBBTUNDIHNob3VsZCBoYXZlIGltcGxlbWVudGVkIG1haWxib3hlcyBhbmQv
b3INCj4+ICAgIGRvb3JiZWxsIHJlZ2lzdGVycyBsaWtlIGFueSBvdGhlciBzYW5lIFBDSSB0YXJn
ZXQNCj4+ICAgIGRldmljZSAoZWcuIHNvbWUgdGhlIEZyZWVzY2FsZSBwcm9jZXNzb3JzLCBvciBh
bnkgb2YNCj4+ICAgIHRoZSBQTFggdGVjaG5vbG9naWVzIGNoaXBzKS4NCj4+DQo+PjIuIExvb2sg
aW4gdGhlIGRhdGEgc2hlZXQgYW5kIHNlZSBpZiB5b3UgY2FuIGZpZ3VyZSBvdXQNCj4+ICAgIGhv
dyB0aGUgaG9zdCBwcm9jZXNzb3IgY2FuIGdlbmVyYXRlIGFuIGludGVycnVwdCB0bw0KPj4gICAg
dGhlIFBvd2VyUEMgY29yZSAuLi4gb29wcywgeW91IGNhbid0LiBUaGF0IGtpbmQgb2YNCj4+ICAg
IG1ha2VzIGl0IGRpZmZpY3VsdCB0byB3b3JrIHdpdGggZG9lc24ndCBpdC4NCj4+DQo+PiAgICBB
IHdvcmsgYXJvdW5kIHdvdWxkIGJlIHRvIGhhdmUgdGhlIGhvc3Qgd3JpdGUgdG8gdGhlDQo+PiAg
ICBHUElPIHJlZ2lzdGVyIGFuZCB3aXJlIGEgR1BJTyBwaW4gYmFjayB0byBhbiBleHRlcm5hbA0K
Pj4gICAgaW50ZXJydXB0IHBpbi4gVGhlbiB5b3Ugd291bGQgbm90IGJlIGFibGUgdG8gdXNlIGFu
eQ0KPj4gICAgb3RoZXIgR1BJTyBwaW4gaW4gdGhhdCBHUElPIHJlZ2lzdGVyIHNpbmNlIHRoZXJl
IGlzDQo+PiAgICBubyB3YXkgdG8gYXJiaXRyYXRlIGhvc3QgYWNjZXNzIHZlcnN1cyBQb3dlclBD
IGNvcmUNCj4+ICAgIGFjY2Vzcy4NCj4+DQo+PlRoaXMgd2FzIHRoZSBvdGhlciByZWFzb24gSSBk
aXRjaGVkIHRoZSBBTUNDIHBhcnQgaW4gZmF2b3Igb2YgdGhlIA0KPj5GcmVlc2NhbGUgcGFydC4N
Cj4+DQo+PklmIHlvdSBhcmUgbG9va2luZyBhdCBvdGhlciBwYXJ0cywgbWFrZSBzdXJlIHlvdSBs
b29rIGluIHRoZSBQQ0kgDQo+PmNvbmZpZ3VyYXRpb24gc3BhY2Ugb2YgdGhlIHByb2Nlc3NvciBy
ZWZlcmVuY2UgbWFudWFsLiBNYW55IHByb2Nlc3NvcnMgDQo+PmhhdmUgdGhlIGludGVycnVwdCBw
aW4gcmVnaXN0ZXIgaGFyZHdpcmVkIHRvIHplcm8sIGkuZS4sIHRoZXkgY2FuIG5vdCANCj4+YmUg
dXNlZCBhcyB0YXJnZXQgZGV2aWNlcywgb25seSBob3N0cy4gSW4gdGhhdCBjYXNlIHlvdSdkIGhh
dmUgdG8gYWRkIA0KPj5hbiBpbnRlbCAyMTU1NSBub24tdHJhbnNwYXJlbnQgYnJpZGdlIHRvIG1h
a2UgdGhlIGRldmljZSBhIHRhcmdldC4NCj4+DQo+PkNoZWVycywNCj4+RGF2ZQ0KPj4NCj4+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+TGludXhwcGMt
ZW1iZWRkZWQgbWFpbGluZyBsaXN0DQo+PkxpbnV4cHBjLWVtYmVkZGVkQG96bGFicy5vcmcNCj4+
aHR0cHM6Ly9vemxhYnMub3JnL21haWxtYW4vbGlzdGluZm8vbGludXhwcGMtZW1iZWRkZWQNCj4N
Cj49ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0NCj4JCQkNCj4NCj6hoaGh
oaGhoaGhoaGhoaGh1sINCj7A8aOhDQo+IA0KPgkJCQkgDQo+oaGhoaGhoaGhoaGhoaGhoXNkZXZl
bi5sZWUNCj6hoaGhoaGhoaGhoaGhoaGhc2RldmVuLmxlZUAxNjMuY29tDQo+oaGhoaGhoaGhoaGh
oaGhoaGhoaEyMDA3LTA5LTA3DQoNCj0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9
ID0gPQ0KCQkJDQoNCqGhoaGhoaGhoaGhoaGhoaHWwg0KwPGjoQ0KIA0KCQkJCSANCqGhoaGhoaGh
oaGhoaGhoaFzZGV2ZW4ubGVlDQqhoaGhoaGhoaGhoaGhoaGhc2RldmVuLmxlZUAxNjMuY29tDQqh
oaGhoaGhoaGhoaGhoaGhoaGhoTIwMDctMDktMDcNCg0K
^ permalink raw reply
* Document and implement an improved flash device binding for powerpc (v5)
From: David Gibson @ 2007-09-07 3:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
This patch replaces the binding for flash chips in
booting-without-of.txt with an clarified and improved version. It
also makes drivers/mtd/maps/physmap_of.c recognize this new binding.
Finally it revises the Ebony device tree source to use the new binding
as an example.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Now with a 'label' property for partitions.
Index: working-2.6/Documentation/powerpc/booting-without-of.txt
===================================================================
--- working-2.6.orig/Documentation/powerpc/booting-without-of.txt 2007-09-07 11:53:10.000000000 +1000
+++ working-2.6/Documentation/powerpc/booting-without-of.txt 2007-09-07 11:53:10.000000000 +1000
@@ -50,7 +50,7 @@ Table of Contents
g) Freescale SOC SEC Security Engines
h) Board Control and Status (BCSR)
i) Freescale QUICC Engine module (QE)
- j) Flash chip nodes
+ j) CFI or JEDEC memory-mapped NOR flash
k) Global Utilities Block
VII - Specifying interrupt information for devices
@@ -1757,45 +1757,69 @@ platforms are moved over to use the flat
};
};
- j) Flash chip nodes
+ j) CFI or JEDEC memory-mapped NOR flash
Flash chips (Memory Technology Devices) are often used for solid state
file systems on embedded devices.
- Required properties:
-
- - device_type : has to be "rom"
- - compatible : Should specify what this flash device is compatible with.
- Currently, this is most likely to be "direct-mapped" (which
- corresponds to the MTD physmap mapping driver).
- - reg : Offset and length of the register set (or memory mapping) for
- the device.
- - bank-width : Width of the flash data bus in bytes. Required
- for the NOR flashes (compatible == "direct-mapped" and others) ONLY.
-
- Recommended properties :
-
- - partitions : Several pairs of 32-bit values where the first value is
- partition's offset from the start of the device and the second one is
- partition size in bytes with LSB used to signify a read only
- partition (so, the partition size should always be an even number).
- - partition-names : The list of concatenated zero terminated strings
- representing the partition names.
- - probe-type : The type of probe which should be done for the chip
- (JEDEC vs CFI actually). Valid ONLY for NOR flashes.
+ - compatible : should contain the specific model of flash chip(s)
+ used, if known, followed by either "cfi-flash" or "jedec-flash"
+ - reg : Address range of the flash chip
+ - bank-width : Width (in bytes) of the flash bank. Equal to the
+ device width times the number of interleaved chips.
+ - device-width : (optional) Width of a single flash chip. If
+ omitted, assumed to be equal to 'bank-width'.
+ - #address-cells, #size-cells : Must be present if the flash has
+ sub-nodes representing partitions (see below). In this case
+ both #address-cells and #size-cells must be equal to 1.
+
+ For JEDEC compatible devices, the following additional properties
+ are defined:
+
+ - vendor-id : Contains the flash chip's vendor id (1 byte).
+ - device-id : Contains the flash chip's device id (1 byte).
+
+ In addition to the information on the flash bank itself, the
+ device tree may optionally contain additional information
+ describing partitions of the flash address space. This can be
+ used on platforms which have strong conventions about which
+ portions of the flash are used for what purposes, but which don't
+ use an on-flash partition table such as RedBoot.
+
+ Each partition is represented as a sub-node of the flash device.
+ Each node's name represents the name of the corresponding
+ partition of the flash device.
+
+ Flash partitions
+ - reg : The partition's offset and size within the flash bank.
+ - label : (optional) The label / name for this flash partition.
+ If omitted, the label is taken from the node name (excluding
+ the unit address).
+ - read-only : (optional) This parameter, if present, is a hint to
+ Linux that this flash partition should only be mounted
+ read-only. This is usually used for flash partitions
+ containing early-boot firmware images or data which should not
+ be clobbered.
- Example:
+ Example:
- flash@ff000000 {
- device_type = "rom";
- compatible = "direct-mapped";
- probe-type = "CFI";
- reg = <ff000000 01000000>;
- bank-width = <4>;
- partitions = <00000000 00f80000
- 00f80000 00080001>;
- partition-names = "fs\0firmware";
- };
+ flash@ff000000 {
+ compatible = "amd,am29lv128ml", "cfi-flash";
+ reg = <ff000000 01000000>;
+ bank-width = <4>;
+ device-width = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ fs@0 {
+ label = "fs";
+ reg = <0 f80000>;
+ };
+ firmware@f80000 {
+ label ="firmware";
+ reg = <f80000 80000>;
+ read-only;
+ };
+ };
k) Global Utilities Block
Index: working-2.6/drivers/mtd/maps/physmap_of.c
===================================================================
--- working-2.6.orig/drivers/mtd/maps/physmap_of.c 2007-08-28 14:23:57.000000000 +1000
+++ working-2.6/drivers/mtd/maps/physmap_of.c 2007-09-07 11:53:10.000000000 +1000
@@ -4,6 +4,9 @@
* Copyright (C) 2006 MontaVista Software Inc.
* Author: Vitaly Wool <vwool@ru.mvista.com>
*
+ * Revised to handle newer style flash binding by:
+ * Copyright (C) 2007 David Gibson, 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
@@ -30,56 +33,135 @@ struct physmap_flash_info {
struct map_info map;
struct resource *res;
#ifdef CONFIG_MTD_PARTITIONS
- int nr_parts;
struct mtd_partition *parts;
#endif
};
-static const char *rom_probe_types[] = { "cfi_probe", "jedec_probe", "map_rom", NULL };
-#ifdef CONFIG_MTD_PARTITIONS
-static const char *part_probe_types[] = { "cmdlinepart", "RedBoot", NULL };
-#endif
-
#ifdef CONFIG_MTD_PARTITIONS
-static int parse_flash_partitions(struct device_node *node,
- struct mtd_partition **parts)
+static int parse_obsolete_partitions(struct of_device *dev,
+ struct physmap_flash_info *info,
+ struct device_node *dp)
{
- int i, plen, retval = -ENOMEM;
- const u32 *part;
- const char *name;
-
- part = of_get_property(node, "partitions", &plen);
- if (part == NULL)
- goto err;
-
- retval = plen / (2 * sizeof(u32));
- *parts = kzalloc(retval * sizeof(struct mtd_partition), GFP_KERNEL);
- if (*parts == NULL) {
+ int i, plen, nr_parts;
+ const struct {
+ u32 offset, len;
+ } *part;
+ const char *names;
+
+ part = of_get_property(dp, "partitions", &plen);
+ if (!part)
+ return -ENOENT;
+
+ dev_warn(&dev->dev, "Device tree uses obsolete partition map binding\n");
+
+ nr_parts = plen / sizeof(part[0]);
+
+ info->parts = kzalloc(nr_parts * sizeof(struct mtd_partition), GFP_KERNEL);
+ if (!info->parts) {
printk(KERN_ERR "Can't allocate the flash partition data!\n");
- goto err;
+ return -ENOMEM;
}
- name = of_get_property(node, "partition-names", &plen);
+ names = of_get_property(dp, "partition-names", &plen);
- for (i = 0; i < retval; i++) {
- (*parts)[i].offset = *part++;
- (*parts)[i].size = *part & ~1;
- if (*part++ & 1) /* bit 0 set signifies read only partition */
- (*parts)[i].mask_flags = MTD_WRITEABLE;
+ for (i = 0; i < nr_parts; i++) {
+ info->parts[i].offset = part->offset;
+ info->parts[i].size = part->len & ~1;
+ if (part->len & 1) /* bit 0 set signifies read only partition */
+ info->parts[i].mask_flags = MTD_WRITEABLE;
- if (name != NULL && plen > 0) {
- int len = strlen(name) + 1;
+ if (names && (plen > 0)) {
+ int len = strlen(names) + 1;
- (*parts)[i].name = (char *)name;
+ info->parts[i].name = (char *)names;
plen -= len;
- name += len;
- } else
- (*parts)[i].name = "unnamed";
+ names += len;
+ } else {
+ info->parts[i].name = "unnamed";
+ }
+
+ part++;
}
-err:
- return retval;
+
+ return nr_parts;
}
-#endif
+
+static int __devinit process_partitions(struct physmap_flash_info *info,
+ struct of_device *dev)
+{
+ const char *partname;
+ static const char *part_probe_types[]
+ = { "cmdlinepart", "RedBoot", NULL };
+ struct device_node *dp = dev->node, *pp;
+ int nr_parts, i;
+
+ /* First look for RedBoot table or partitions on the command
+ * line, these take precedence over device tree information */
+ nr_parts = parse_mtd_partitions(info->mtd, part_probe_types,
+ &info->parts, 0);
+ if (nr_parts > 0) {
+ add_mtd_partitions(info->mtd, info->parts, nr_parts);
+ return 0;
+ }
+
+ /* First count the subnodes */
+ nr_parts = 0;
+ for (pp = dp->child; pp; pp = pp->sibling)
+ nr_parts++;
+
+ if (nr_parts) {
+ info->parts = kzalloc(nr_parts * sizeof(struct mtd_partition),
+ GFP_KERNEL);
+ if (!info->parts) {
+ printk(KERN_ERR "Can't allocate the flash partition data!\n");
+ return -ENOMEM;
+ }
+
+ for (pp = dp->child, i = 0 ; pp; pp = pp->sibling, i++) {
+ const u32 *reg;
+ int len;
+
+ reg = of_get_property(pp, "reg", &len);
+ if (!reg || (len != 2*sizeof(u32))) {
+ dev_err(&dev->dev, "Invalid 'reg' on %s\n",
+ dp->full_name);
+ kfree(info->parts);
+ info->parts = NULL;
+ return -EINVAL;
+ }
+ info->parts[i].offset = reg[0];
+ info->parts[i].size = reg[1];
+
+ partname = of_get_property(pp, "label", &len);
+ if (!partname)
+ partname = of_get_property(pp, "name", &len);
+ info->parts[i].name = (char *)partname;
+
+ if (of_get_property(pp, "read-only", &len))
+ info->parts[i].mask_flags = MTD_WRITEABLE;
+ }
+ } else {
+ nr_parts = parse_obsolete_partitions(dev, info, dp);
+ }
+
+ if (nr_parts < 0)
+ return nr_parts;
+
+ if (nr_parts > 0)
+ add_mtd_partitions(info->mtd, info->parts, nr_parts);
+ else
+ add_mtd_device(info->mtd);
+
+ return 0;
+}
+#else /* MTD_PARTITIONS */
+static int __devinit process_partitions(struct physmap_flash_info *info,
+ struct device_node *dev)
+{
+ add_mtd_device(info->mtd);
+ return 0;
+}
+#endif /* MTD_PARTITIONS */
static int of_physmap_remove(struct of_device *dev)
{
@@ -92,7 +174,7 @@ static int of_physmap_remove(struct of_d
if (info->mtd != NULL) {
#ifdef CONFIG_MTD_PARTITIONS
- if (info->nr_parts) {
+ if (info->parts) {
del_mtd_partitions(info->mtd);
kfree(info->parts);
} else {
@@ -115,17 +197,51 @@ static int of_physmap_remove(struct of_d
return 0;
}
+/* Helper function to handle probing of the obsolete "direct-mapped"
+ * compatible binding, which has an extra "probe-type" property
+ * describing the type of flash probe necessary. */
+static struct mtd_info * __devinit obsolete_probe(struct of_device *dev,
+ struct map_info *map)
+{
+ struct device_node *dp = dev->node;
+ const char *of_probe;
+ struct mtd_info *mtd;
+ static const char *rom_probe_types[]
+ = { "cfi_probe", "jedec_probe", "map_rom"};
+ int i;
+
+ dev_warn(&dev->dev, "Device tree uses obsolete \"direct-mapped\" "
+ "flash binding\n");
+
+ of_probe = of_get_property(dp, "probe-type", NULL);
+ if (!of_probe) {
+ for (i = 0; i < ARRAY_SIZE(rom_probe_types); i++) {
+ mtd = do_map_probe(rom_probe_types[i], map);
+ if (mtd)
+ return mtd;
+ }
+ return NULL;
+ } else if (strcmp(of_probe, "CFI") == 0) {
+ return do_map_probe("cfi_probe", map);
+ } else if (strcmp(of_probe, "JEDEC") == 0) {
+ return do_map_probe("jedec_probe", map);
+ } else {
+ if (strcmp(of_probe, "ROM") != 0)
+ dev_dbg(&dev->dev, "obsolete_probe: don't know probe type "
+ "'%s', mapping as rom\n", of_probe);
+ return do_map_probe("mtd_rom", map);
+ }
+}
+
static int __devinit of_physmap_probe(struct of_device *dev, const struct of_device_id *match)
{
struct device_node *dp = dev->node;
struct resource res;
struct physmap_flash_info *info;
- const char **probe_type;
- const char *of_probe;
+ const char *probe_type = (const char *)match->data;
const u32 *width;
int err;
-
if (of_address_to_resource(dp, 0, &res)) {
dev_err(&dev->dev, "Can't get the flash mapping!\n");
err = -EINVAL;
@@ -174,21 +290,11 @@ static int __devinit of_physmap_probe(st
simple_map_init(&info->map);
- of_probe = of_get_property(dp, "probe-type", NULL);
- if (of_probe == NULL) {
- probe_type = rom_probe_types;
- for (; info->mtd == NULL && *probe_type != NULL; probe_type++)
- info->mtd = do_map_probe(*probe_type, &info->map);
- } else if (!strcmp(of_probe, "CFI"))
- info->mtd = do_map_probe("cfi_probe", &info->map);
- else if (!strcmp(of_probe, "JEDEC"))
- info->mtd = do_map_probe("jedec_probe", &info->map);
- else {
- if (strcmp(of_probe, "ROM"))
- dev_dbg(&dev->dev, "map_probe: don't know probe type "
- "'%s', mapping as rom\n", of_probe);
- info->mtd = do_map_probe("mtd_rom", &info->map);
- }
+ if (probe_type)
+ info->mtd = do_map_probe(probe_type, &info->map);
+ else
+ info->mtd = obsolete_probe(dev, &info->map);
+
if (info->mtd == NULL) {
dev_err(&dev->dev, "map_probe failed\n");
err = -ENXIO;
@@ -196,19 +302,7 @@ static int __devinit of_physmap_probe(st
}
info->mtd->owner = THIS_MODULE;
-#ifdef CONFIG_MTD_PARTITIONS
- err = parse_mtd_partitions(info->mtd, part_probe_types, &info->parts, 0);
- if (err > 0) {
- add_mtd_partitions(info->mtd, info->parts, err);
- } else if ((err = parse_flash_partitions(dp, &info->parts)) > 0) {
- dev_info(&dev->dev, "Using OF partition information\n");
- add_mtd_partitions(info->mtd, info->parts, err);
- info->nr_parts = err;
- } else
-#endif
-
- add_mtd_device(info->mtd);
- return 0;
+ return process_partitions(info, dev);
err_out:
of_physmap_remove(dev);
@@ -221,6 +315,21 @@ err_out:
static struct of_device_id of_physmap_match[] = {
{
+ .compatible = "cfi-flash",
+ .data = (void *)"cfi_probe",
+ },
+ {
+ /* FIXME: JEDEC chips can't be safely and reliably
+ * probed, although the mtd code gets it right in
+ * practice most of the time. We should use the
+ * vendor and device ids specified by the binding to
+ * bypass the heuristic probe code, but the mtd layer
+ * provides, at present, no interface for doing so
+ * :(. */
+ .compatible = "jedec-flash",
+ .data = (void *)"jedec_probe",
+ },
+ {
.type = "rom",
.compatible = "direct-mapped"
},
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-09-05 15:56:35.000000000 +1000
+++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-09-07 11:53:10.000000000 +1000
@@ -142,13 +142,16 @@
interrupt-parent = <&UIC1>;
small-flash@0,80000 {
- device_type = "rom";
- compatible = "direct-mapped";
- probe-type = "JEDEC";
+ compatible = "jedec-flash";
bank-width = <1>;
- partitions = <0 80000>;
- partition-names = "OpenBIOS";
reg = <0 80000 80000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "OpenBIOS";
+ reg = <0 80000>;
+ read-only;
+ };
};
ds1743@1,0 {
@@ -158,14 +161,19 @@
};
large-flash@2,0 {
- device_type = "rom";
- compatible = "direct-mapped";
- probe-type = "JEDEC";
+ compatible = "jedec-flash";
bank-width = <1>;
- partitions = <0 380000
- 380000 80000>;
- partition-names = "fs", "firmware";
reg = <2 0 400000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "fs";
+ reg = <0 380000>;
+ };
+ partition@380000 {
+ label = "firmware";
+ reg = <380000 80000>;
+ };
};
ir@3,0 {
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 2/6] cuimage for Bamboo board
From: David Gibson @ 2007-09-07 3:26 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070905114243.3c787838@weaponx.rchland.ibm.com>
On Wed, Sep 05, 2007 at 11:42:43AM -0500, Josh Boyer wrote:
> Updated patch below. NOTE: This relies on Scott Wood's strtoull patch
> as PIBS stores the MAC addresses as ASCII strings in flash.
>
>
> Add a cuboot wrapper for the Bamboo board. This also removes some obsoleted
> linker declarations that have been moved into ops.h
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Except..
[snip]
> --- linux-2.6.orig/arch/powerpc/boot/treeboot-bamboo.c
> +++ linux-2.6/arch/powerpc/boot/treeboot-bamboo.c
It's not the fault of this patch, but since bamboo actually boots from
PIBS, not OpenBIOS, it probably shouldn't be lumped in with the
treeboot stuff. PIBS should be able to load ELF images directly,
rather than using the silly treeboot header, for one thing.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: David Gibson @ 2007-09-07 3:37 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <3299c27fe2551315c6f5ecff3569f2e0@kernel.crashing.org>
On Thu, Sep 06, 2007 at 04:13:56PM +0200, Segher Boessenkool wrote:
> >> This kind of thing is typically hardcoded into the firmware (just like
> >> the device tree is) -- just put it somewhere _next to_ the device
> >> tree,
> >> not _in_ it.
> >
> > What is next to the device tree?
>
> "Anywhere else in the firmware".
>
> > AFAIK, there is no other standard data structure that could take place
> > of the par_io nodes in the DTS.
>
> The device tree is not a dumping ground for all your "I need some
> standard data structure" stuff. Use an XML file if you have to ;-)
Actually, I think "I need a standard data structure" is well within
the purview of what we hoped the flat device tree could do. We don't
have to follow IEEE1275 slavishly.
To isolate this sort of thing out from the device tree "proper", we
may wish to define some new "virtual" device nodes to go at the root
level (in the same way that /chosen and /aliases already have defined
purposes that don't involve describing real devices).
I can't speak specifically to the par_io nodes, because their function
was not obvious to me from my glance at the examples we have, and I
don't recall whatever previous discussions they were described in.
We do want, where possible, though, to make it unambiguous what things
are describing immutable facts about the hardware and what are hints
or startup configuration only.
> > I agree with your points, Segher, but replacing the par_io node with a
> > bunch of par_io_config_pin() calls in the kernel is not really an
> > improvement, I think. Until we migrate the QE pin configuration code
> > to U-boot, I suggest that we keep the device tree structure as-is and
> > continue to use it for new code. That way, it will all stay in one
> > place.
>
> Sure, some migration plan is in order, things won't change overnight.
> That doesn't mean you don't need to start planning _now_ ;-)
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Flash Filesystem
From: schardt @ 2007-09-07 7:34 UTC (permalink / raw)
To: Linux PPC Linux PPC
Hi
i've some problems using the on board flash memory with linux.
i added the support for adm/fujittsu flash in kernel config and add the
right parameters for the "cfi flash device in physical memory".
cat /proc/mtd gives me
dev: size erasesize name
mtd0: 00400000 00010000 "physmap-flash.0"
i added /dev/mtd0 c 90 0 and /dev/mtdblock0 b 31 0
how do i add a partition and filesystem ????
fdisk /dev/mtd0 seems me not to be correct :)
Greets
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/PATCH 1/2] Basic generic time/clocksource code for PowerPC
From: Gabriel Paubert @ 2007-09-07 8:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070906172415.GA18226@ld0162-tx32.am.freescale.net>
On Thu, Sep 06, 2007 at 12:24:15PM -0500, Scott Wood wrote:
> On Thu, Sep 06, 2007 at 07:05:47PM +0200, Gabriel Paubert wrote:
> > On Thu, Sep 06, 2007 at 12:01:23PM -0500, Scott Wood wrote:
> > > On Thu, Sep 06, 2007 at 06:55:35PM +0200, Gabriel Paubert wrote:
> > > > So who will be in charge of updating the RTC now? The update
> > > > every 11 min is there to stay on x86(-64) it seems.
> > >
> > > Put something in crontab to run hwclock periodically.
> >
> > I have many machines on which cron is not even installed.
>
> OK, so use something else that waits in a loop and periodically updates
> the clock. It shouldn't be the kernel's responsibility.
It ha been the kernel's reposnibility ever since the NTP code
was included with the kernel. The only way to move it out
is to agree to something with NTP folks.
It is going to break working setups who rely on this feature,
which is a big no-no.
The solution now used by i386/x86-64/sparc64 is
CONFIG_GENERIC_CMOS_UPDATE. Maybe powerpc should be switched
to use something similar, but the generic code has some
problems (it assumes that you have to set the clock
on a half-second, which is not the case of the RTC on
my boards to start with).
Now I'm aware that some PowerPC RTC are messy to handle
in a timer/interrupt/whatever because some hardware designers
thought it was wise to put the RTC on a dog-slow bus like
I2C. You have however a variable to disable this update
if you want (no_sync_cmos_clock), set it to 1 by default
but please let people that use (and need) the functionality
enable it (even do it by default when the RTC access is fast).
Gabriel
^ permalink raw reply
* Re: [PATCH 2.6.23] PS3: Ignore storage devices that are still being probed
From: Geoff Levand @ 2007-09-07 8:49 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Andrew Morton, Paul Mackerras,
Cell Broadband Engine OSS Development
In-Reply-To: <Pine.LNX.4.62.0709061813090.22591@pademelon.sonytel.be>
Geert Uytterhoeven wrote:
> PS3: A storage device may show up in the repository before the hypervisor has
> finished probing:
> - If its type is not yet known, it shows up as PS3_DEV_TYPE_STOR_DUMMY,
> - If its regions are being probed, it shows up as having zero regions.
> If any of these happen, consider the device not yet present. The storage
> probe thread will retry later.
>
> This fixes the timing-dependent problem where a kernel booted from FLASH ROM
> sometimes cannot find the hard disk.
>
> Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Paul,
This fixes a problem reported by users, so it would be nice for it to go
in for 2.6.23 if possible. Sorry for it being so late.
Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>
^ permalink raw reply
* Re: [RFC/PATCH 1/2] Basic generic time/clocksource code for PowerPC
From: Gabriel Paubert @ 2007-09-07 8:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18144.17628.612658.91528@cargo.ozlabs.ibm.com>
On Fri, Sep 07, 2007 at 04:20:12AM +1000, Paul Mackerras wrote:
> Gabriel Paubert writes:
>
> > On Fri, Sep 07, 2007 at 12:41:38AM +1000, Paul Mackerras wrote:
> > > This changes PowerPC to use the generic time infrastructure for
> > > gettimeofday et al. We register a clocksource which uses the timebase
> > > register, or the RTC on the 601.
> > >
> > > It also gets rid of the RTC update stuff. IIRC we discussed removing
> > > this some time ago but never actually did it.
> >
> > So who will be in charge of updating the RTC now? The update
> > every 11 min is there to stay on x86(-64) it seems.
>
> I had an impression that ntpd would do it, but that seems to be wrong.
>
> I also have been unable to find where in the kernel source there is
> code for x86[-64] to do the RTC updates. Do you know where it is?
It goes through CONFIG_CMOS_UPDATE, which is set to Y by default
on i386/x86-64/sparc64.
>
> Doing the updates from timer_interrupt will no longer really be
> suitable since it is not called at regular intervals any more. The
> best thing would be for the ntp code to set up a timer when it reaches
> synchronization.
This is what CONFIG_CMOS_UPDATE does through the sync_cmos_timer
variable.
>
> > Removing this will have strange side effects: as an example,
> > your laptop clock will be good if it synchronized on NTP,
> > then you put it to sleep, disconnect the network and RTC read
> > on wake up returns a wrong value, giving wrong timestamps.
>
> No, the suspend/resume code reads the RTC on both suspend and resume,
> and advances xtime by the difference between the two readings. So the
> time might be out by up to a second after resume, but it shouldn't be
> way off, assuming that your RTC is advancing at the right speed.
Ok, I did not know this. Well, my PreP boards never sleep (not worth
when doing real time data acquisition at 100-200 Hz interrupt rate)
but I rely on ntp and a fairly precise time setup at boot in some cases.
Actually I have slightly modified my kernels: I loop waiting
for the second boundary to set the time and also use one full
second of the RTC to calibrate the timebase, even that has
its own issues since I cannot use the last and first second
of every minute because of RTC vagaries:
http://www.st.com/stonline/products/literature/an/5228.pdf
and that does not describe also the calibration which shortens
or lengthens also specific seconds but I can afford to
systematically set the calibration factor to 0:
http://www.st.com/stonline/products/literature/an/6393.pdf
This is the only way I found to have reproducible timebase
measurements on these machines; it means that it takes up to
3 seconds to calibrate the timebase at boot, but it's better
than to have ntp error rate starting to depend on the phase
of the moon (this was my impression when I first found the
problem :-)), or more precisely on which second in the minute
the timebase calibration is performed.
>
> > As someone who has a network of tens of machines using
> > NTP for synchornisation I think it is a very bad idea
> > unless we have a replacement.
>
> OK, but I think that doing it in timer_interrupt is the wrong place.
Indeed, but please bring up something using the CONFIG_CMOS_UPDATE
infrastructure. I'm aware that some RTC have awfully slow accesses
(the more recent, the longest the latency it seems), but it is always
possible to disable it through the no_sync_cmos_clock variable.
Default it to 1 if you want, after all it should not be the job
of the kernel if you have an hypervisor too, I don't care as long as
you give me the possibility of enabling automatic RTC updates.
Regards,
Gabriel
^ permalink raw reply
* Re: [PATCH] powerpc: Add workaround for MPICs with broken register reads
From: Olof Johansson @ 2007-09-07 9:16 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <d62ce2299f9d423f95cd8ee50b3b7cff@bga.com>
On Thu, Sep 06, 2007 at 09:55:21AM -0500, Milton Miller wrote:
> On Wed Sep 5 12:44:17 EST 2007, Olof Johansson wrote:
>> diff --git a/arch/powerpc/platforms/Kconfig
>> b/arch/powerpc/platforms/Kconfig
>> index 041df77..b9f1efa 100644
>> --- a/arch/powerpc/platforms/Kconfig
>> +++ b/arch/powerpc/platforms/Kconfig
>> @@ -137,6 +137,10 @@ config MPIC_U3_HT_IRQS
>> depends on PPC_MAPLE
>> default y
>>
>> +config MPIC_BROKEN_REGREAD
>> + bool
>> + depends on PPC_PASEMI
>> +
>> config IBMVIO
>> depends on PPC_PSERIES || PPC_ISERIES
>> bool
>> diff --git a/arch/powerpc/platforms/pasemi/Kconfig
>> b/arch/powerpc/platforms/pasemi/Kconfig
>> index 95cd90f..117d90a 100644
>> --- a/arch/powerpc/platforms/pasemi/Kconfig
>> +++ b/arch/powerpc/platforms/pasemi/Kconfig
>> @@ -5,6 +5,7 @@ config PPC_PASEMI
>> select MPIC
>> select PPC_UDBG_16550
>> select PPC_NATIVE
>> + select MPIC_BROKEN_REGREAD
>> help
>> This option enables support for PA Semi's PWRficient line
>> of SoC processors, including PA6T-1682M
>
>
> Since you are using select (and not default y), instead of the depends on
> PPC_PASEMI how about adding a short description of what the config does as
> help text, in case some future mpic has a similar bug?
Thanks Milton, that's a reasonable suggestion (not that any of the other
options do it, including the very vague MPIC_WEIRD :-).
New patch posted shortly.
-Olof
^ permalink raw reply
* [PATCH v2] powerpc: Add workaround for MPICs with broken register reads
From: Olof Johansson @ 2007-09-07 9:21 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, miltonm
In-Reply-To: <20070905024417.GE27139@lixom.net>
Some versions of PWRficient 1682M have an interrupt controller in which
the first register in each pair for interrupt sources doesn't always
read with the right polarity/sense values.
To work around this, keep a software copy of the register instead. Since
it's not modified from the mpic itself, it's a feasible solution. Still,
keep it under a config option to avoid wasting memory on other platforms.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 041df77..f2e7049 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -137,6 +137,18 @@ config MPIC_U3_HT_IRQS
depends on PPC_MAPLE
default y
+config MPIC_BROKEN_REGREAD
+ bool "MPIC workaround for broken register reads"
+ depends on MPIC
+ help
+ Say Y here to enable a MPIC driver workaround for some chips that
+ have a bug that causes some interrupt source information to not
+ read back properly. It is safe to use on other chips as well, but
+ enabling it uses about 8KB of memory to keep copies of the register
+ contents in software.
+
+ Say N if you are unsure.
+
config IBMVIO
depends on PPC_PSERIES || PPC_ISERIES
bool
diff --git a/arch/powerpc/platforms/pasemi/Kconfig b/arch/powerpc/platforms/pasemi/Kconfig
index 95cd90f..117d90a 100644
--- a/arch/powerpc/platforms/pasemi/Kconfig
+++ b/arch/powerpc/platforms/pasemi/Kconfig
@@ -5,6 +5,7 @@ config PPC_PASEMI
select MPIC
select PPC_UDBG_16550
select PPC_NATIVE
+ select MPIC_BROKEN_REGREAD
help
This option enables support for PA Semi's PWRficient line
of SoC processors, including PA6T-1682M
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 74c64c0..c0fe063 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -228,8 +228,13 @@ static inline u32 _mpic_irq_read(struct mpic *mpic, unsigned int src_no, unsigne
unsigned int isu = src_no >> mpic->isu_shift;
unsigned int idx = src_no & mpic->isu_mask;
- return _mpic_read(mpic->reg_type, &mpic->isus[isu],
- reg + (idx * MPIC_INFO(IRQ_STRIDE)));
+#ifdef CONFIG_MPIC_BROKEN_REGREAD
+ if (reg == 0)
+ return mpic->isu_reg0_shadow[idx];
+ else
+#endif
+ return _mpic_read(mpic->reg_type, &mpic->isus[isu],
+ reg + (idx * MPIC_INFO(IRQ_STRIDE)));
}
static inline void _mpic_irq_write(struct mpic *mpic, unsigned int src_no,
@@ -240,6 +245,11 @@ static inline void _mpic_irq_write(struct mpic *mpic, unsigned int src_no,
_mpic_write(mpic->reg_type, &mpic->isus[isu],
reg + (idx * MPIC_INFO(IRQ_STRIDE)), value);
+
+#ifdef CONFIG_MPIC_BROKEN_REGREAD
+ if (reg == 0)
+ mpic->isu_reg0_shadow[idx] = value;
+#endif
}
#define mpic_read(b,r) _mpic_read(mpic->reg_type,&(b),(r))
diff --git a/include/asm-powerpc/mpic.h b/include/asm-powerpc/mpic.h
index 262db6b..c877fa7 100644
--- a/include/asm-powerpc/mpic.h
+++ b/include/asm-powerpc/mpic.h
@@ -309,6 +309,10 @@ struct mpic
unsigned long *hwirq_bitmap;
#endif
+#ifdef CONFIG_MPIC_BROKEN_REGREAD
+ u32 isu_reg0_shadow[MPIC_MAX_IRQ_SOURCES];
+#endif
+
/* link */
struct mpic *next;
^ permalink raw reply related
* Re: How to use MMC-over-SPI on MPC8313E
From: Vitaly Bordug @ 2007-09-07 9:22 UTC (permalink / raw)
To: Vinu; +Cc: linuxppc-dev
In-Reply-To: <46E02F48.6090005@gen10technology.com>
On Thu, 06 Sep 2007 11:48:08 -0500
Vinu wrote:
> Hi all,
>
> I am working on MPC8313ERDB Eval board, and want to use SD Memory
> card to store Linux OS and file system.
> The SD card controller is connected directly with the SPI bus.
>
> I simply don't know how to use MMC-over-SPI technology to make SD
> card usable.
>
> It would be a great help if anybody have any documentation or driver
> etc.
>
Please search list - there is 8323 support... We /mvista/ did such a thing not long ago. All the stuff releated to spi/mmc layer is already in mainline kernel, you'll just need to do board-specific patch for 8313 which should be similar to mentioned.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: How to use MMC-over-SPI on MPC8313E
From: Sven Luther @ 2007-09-07 9:59 UTC (permalink / raw)
To: Vinu; +Cc: linuxppc-dev
In-Reply-To: <46E02F48.6090005@gen10technology.com>
On Thu, Sep 06, 2007 at 11:48:08AM -0500, Vinu wrote:
> Hi all,
>
> I am working on MPC8313ERDB Eval board, and want to use SD Memory card
> to store Linux OS and file system.
> The SD card controller is connected directly with the SPI bus.
>
> I simply don't know how to use MMC-over-SPI technology to make SD card
> usable.
>
> It would be a great help if anybody have any documentation or driver etc.
I have recently written a MMC-over-SPI driver for a MPC875 card. It used
the block device directly, and is rather straightforward, but maybe not
so nice as it could be. I need to unbrand it, and can send it to you
later on. Please ping me this WE if you are interested.
Friendly,
Sven Luther
^ permalink raw reply
* [PATCH 1/2][RESEND] ehea: propagate physical port state
From: Jan-Bernd Themann @ 2007-09-07 10:30 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
Introduces a module parameter to decide whether the physical
port link state is propagated to the network stack or not.
It makes sense not to take the physical port state into account
on machines with more logical partitions that communicate
with each other. This is always possible no matter what the physical
port state is. Thus eHEA can be considered as a switch there.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
drivers/net/ehea/ehea.h | 5 ++++-
drivers/net/ehea/ehea_main.c | 14 +++++++++++++-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index d67f97b..8d58be5 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0073"
+#define DRV_VERSION "EHEA_0074"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
@@ -402,6 +402,8 @@ struct ehea_mc_list {
#define EHEA_PORT_UP 1
#define EHEA_PORT_DOWN 0
+#define EHEA_PHY_LINK_UP 1
+#define EHEA_PHY_LINK_DOWN 0
#define EHEA_MAX_PORT_RES 16
struct ehea_port {
struct ehea_adapter *adapter; /* adapter that owns this port */
@@ -427,6 +429,7 @@ struct ehea_port {
u32 msg_enable;
u32 sig_comp_iv;
u32 state;
+ u8 phy_link;
u8 full_duplex;
u8 autoneg;
u8 num_def_qps;
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index db57474..1e9fd6f 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -53,17 +53,21 @@ static int rq3_entries = EHEA_DEF_ENTRIES_RQ3;
static int sq_entries = EHEA_DEF_ENTRIES_SQ;
static int use_mcs = 0;
static int num_tx_qps = EHEA_NUM_TX_QP;
+static int prop_carrier_state = 0;
module_param(msg_level, int, 0);
module_param(rq1_entries, int, 0);
module_param(rq2_entries, int, 0);
module_param(rq3_entries, int, 0);
module_param(sq_entries, int, 0);
+module_param(prop_carrier_state, int, 0);
module_param(use_mcs, int, 0);
module_param(num_tx_qps, int, 0);
MODULE_PARM_DESC(num_tx_qps, "Number of TX-QPS");
MODULE_PARM_DESC(msg_level, "msg_level");
+MODULE_PARM_DESC(prop_carrier_state, "Propagate carrier state of physical "
+ "port to stack. 1:yes, 0:no. Default = 0 ");
MODULE_PARM_DESC(rq3_entries, "Number of entries for Receive Queue 3 "
"[2^x - 1], x = [6..14]. Default = "
__MODULE_STRING(EHEA_DEF_ENTRIES_RQ3) ")");
@@ -814,7 +818,9 @@ int ehea_set_portspeed(struct ehea_port *port, u32 port_speed)
ehea_error("Failed setting port speed");
}
}
- netif_carrier_on(port->netdev);
+ if (!prop_carrier_state || (port->phy_link == EHEA_PHY_LINK_UP))
+ netif_carrier_on(port->netdev);
+
kfree(cb4);
out:
return ret;
@@ -869,13 +875,19 @@ static void ehea_parse_eqe(struct ehea_adapter *adapter, u64 eqe)
}
if (EHEA_BMASK_GET(NEQE_EXTSWITCH_PORT_UP, eqe)) {
+ port->phy_link = EHEA_PHY_LINK_UP;
if (netif_msg_link(port))
ehea_info("%s: Physical port up",
port->netdev->name);
+ if (prop_carrier_state)
+ netif_carrier_on(port->netdev);
} else {
+ port->phy_link = EHEA_PHY_LINK_DOWN;
if (netif_msg_link(port))
ehea_info("%s: Physical port down",
port->netdev->name);
+ if (prop_carrier_state)
+ netif_carrier_off(port->netdev);
}
if (EHEA_BMASK_GET(NEQE_EXTSWITCH_PRIMARY, eqe))
--
1.5.2
^ permalink raw reply related
* [PATCH 2/2][RESEND] ehea: fix last_rx update
From: Jan-Bernd Themann @ 2007-09-07 10:30 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
Update last_rx in registered device struct instead of
in the dummy device.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
drivers/net/ehea/ehea_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 1e9fd6f..717b129 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -471,7 +471,7 @@ static struct ehea_cqe *ehea_proc_rwqes(struct net_device *dev,
else
netif_receive_skb(skb);
- dev->last_rx = jiffies;
+ port->netdev->last_rx = jiffies;
} else {
pr->p_stats.poll_receive_errors++;
port_reset = ehea_treat_poll_error(pr, rq, cqe,
--
1.5.2
^ permalink raw reply related
* [PATCH 0/5] DMA engine driver for Freescale MPC85xx processors.
From: Zhang Wei @ 2007-09-07 10:53 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi,
These patches are DMA engine driver for Freescale MPC85xx processors
which the update for supporting new DMA engine API.
[PATCH 1/5] Add Freescale DMA and DMA channel to Documentation/powerpc/booting-without-of.txt file.
[PATCH 2/5] Add Freescale DMA engine driver maintainer.
[PATCH 3/5] Add DMA of-node to mpc8641hpcn board dts
[PATCH 4/5] Add of-device and DMA bus support to MPC8641HPCN board.
[PATCH 5/5] Add DMA engine driver for Freescale MPC85xx processors.
Best Regards,
Zhang Wei
^ permalink raw reply
* [PATCH 1/5] Add Freescale DMA and DMA channel to Documentation/powerpc/booting-without-of.txt file.
From: Zhang Wei @ 2007-09-07 10:53 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <11891624353752-git-send-email-wei.zhang@freescale.com>
This patch adds Freescale DMA and DMA channel definition to
Documentation/powerpc/booting-without-of.txt file.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Signed-off-by: Ebony Zhu <ebony.zhu@freescale.com>
---
Documentation/powerpc/booting-without-of.txt | 67 ++++++++++++++++++++++++++
1 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 76733a3..d114edf 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -52,6 +52,8 @@ Table of Contents
i) Freescale QUICC Engine module (QE)
j) Flash chip nodes
k) Global Utilities Block
+ l) Freescale DMA
+ m) Freescale DMA channel
VII - Specifying interrupt information for devices
1) interrupts property
@@ -1824,6 +1826,71 @@ platforms are moved over to use the flattened-device-tree model.
fsl,has-rstcr;
};
+ l) Freescale DMA
+
+ The DMA for dma-engine driver of Freescale MPC8540 silicon DMA
+ controller which also fit for MPC8560, MPC8555,
+ MPC8548, MPC8641 and MPC8349 silicon DMA controller,
+
+ For each DMA node, you should define channels included.
+ Please see below 'm) Freescale DMA channel' for DMA channel's definition.
+
+ Required properties:
+
+ - compatible : Should be "fsl,dma".
+ - reg : Offset and length of DMA general status register.
+ - ranges : Should be defined as specified in 1) to describe the
+ DMA controller channels.
+
+ Example:
+ dma@21000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,dma";
+ reg = <21300 4>;
+ ranges = <0 21100 200>;
+ dma-channel@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8540-dma-channel";
+ reg = <0 80>;
+ interrupt-parent = <&mpic>;
+ interrupts = <14 2>;
+ };
+ dma-channel@80 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8540-dma-channel";
+ reg = <80 80>;
+ interrupt-parent = <&mpic>;
+ interrupts = <15 2>;
+ };
+ dma-channel@100 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8540-dma-channel";
+ reg = <100 80>;
+ interrupt-parent = <&mpic>;
+ interrupts = <16 2>;
+ };
+ dma-channel@180 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8540-dma-channel";
+ reg = <180 80>;
+ interrupt-parent = <&mpic>;
+ interrupts = <17 2>;
+ };
+ };
+
+ m) Freescale DMA channel
+
+ Required properties:
+
+ - compatible : Should be "fsl,mpc8540-dma-channel"
+ or "fsl,mpc8349-dma-channel"
+ - reg : Offset and length of the register set for the DMA channel.
+
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices
--
1.5.2
^ permalink raw reply related
* [PATCH 2/5] Add Freescale DMA engine driver maintainer.
From: Zhang Wei @ 2007-09-07 10:53 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <1189162437484-git-send-email-wei.zhang@freescale.com>
This patch adds Freescale DMA engine driver maintainer.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
---
MAINTAINERS | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 01f222e..1be4f23 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1527,6 +1527,13 @@ L: linux-fbdev-devel@lists.sourceforge.net (subscribers-only)
W: http://linux-fbdev.sourceforge.net/
S: Maintained
+FREESCALE DMA DRIVER
+P; Zhang Wei
+M: wei.zhang@freescale.com
+L: linuxppc-embedded@ozlabs.org
+L: linux-kernel@vger.kernel.org
+S: Maintained
+
FREESCALE SOC FS_ENET DRIVER
P: Pantelis Antoniou
M: pantelis.antoniou@gmail.com
--
1.5.2
^ permalink raw reply related
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