On Tuesday 11 March 2008 23:40, David Gibson wrote: > On Tue, Mar 11, 2008 at 11:39:08AM +0100, Laurent Pinchart wrote: > > On Tuesday 11 March 2008 01:45, David Gibson wrote: > > > On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote: > > > > [EMAIL PROTECTED] wrote: > [snip] > > > > We ran ito the same issue. > > > > We did option 3, as it was efinetly the easiest, > > > > > > I think this is the best option in principle. > > > > I'll implement that and post a patch after completing the ppc-to-powerpc > > migration. > > > > > > here is the sram entry in our dts: > > > > > > Except that your implementation of it is not good. > > > > > > You're relying on the old obsolete flash binding with the "probe-type" > > > field. The solution should be adapted to the new approach which uses > > > values in the "compatible" field to indicate various sorts of flash > > > device. > > > > What "compatible" values should I use for ROM and RAM mappings ? > > That I'm not so sure of. We'll need to find some consensus. > > There may be existing IEEE1275 bindings for roms, which we should > investigate.
Do you (or someone else here) have access to the IEEE1275 specification ? Is
there any ROM binding in there ?
> Arguably RAM should be represented by a memory node, but
> that's going to get messy for this sort of application.
We're talking about a very specific type of RAM, used for permanent storage
with a battery backup. The RAM is really meant to be used as an MTD device
and as such I think it makes sense to describe it as an mtd-compatible device
on the local bus.
What about the following definition for the RAM node ?
[EMAIL PROTECTED],0000 {
compatible = "mtd,ram";
reg = <2 0x0000 0x00100000>;
bank-width = <2>;
};
Or should the node have a device-type property of either 'ram' or 'rom' with
the compatible property just referencing MTD ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
pgpBeTwQpIHsf.pgp
Description: PGP signature
_______________________________________________ Linuxppc-dev mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-dev
