OF compatible MTD platform RAM driver ?

OF compatible MTD platform RAM driver ?

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

Hi everybody,

as part of a ARCH=ppc to ARCH=powerpc migration process, I'm looking for an 
OpenFirmware compatible way to handle a RAM-based MTD device.

On the platform_device based ppc architecture, the drivers/mtd/maps/plat-ram.c 
driver handled "mtd-ram" platform devices. There is no such driver for the 
OF-based powerpc architecture.

As a temporary workaround I hacked the physmap_of driver to 
handle "direct-mapped" OF devices oh type "ram" by adding a corresponding 
entry in the of_flash_match[] array. This seems to work fine.

What would be the preferred way to handle OF-compatible RAM-based MTD 
devices ? The 3 ways I can think of are

1. porting the plat-ram driver to OF (the driver isn't used in the kernel tree 
but I suspect it is used by out-of-tree boards)

2. creating a new plat-ram-of driver, much like the physmap_of driver comes 
from the physmap driver

3. extending the physmap_of driver to handle RAM devices (in which case 
references to "flash" in the function names should probably be replaced 
by "mtd")

I live option 3 better so far.

Has anyone already worked on this ? Is there any defined device tree mapping 
for MTD RAM devices ?

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: OF compatible MTD platform RAM driver ?

[Rune Torgersen]

linuxppc-dev-bounces+runet=3Dinnovsys.com@ozlabs.org wrote:
> Hi everybody,
>=20
> as part of a ARCH=3Dppc to ARCH=3Dpowerpc migration process, I'm
> looking for an
> OpenFirmware compatible way to handle a RAM-based MTD device.
>=20
> On the platform_device based ppc architecture, the
> drivers/mtd/maps/plat-ram.c
> driver handled "mtd-ram" platform devices. There is no such
> driver for the
> OF-based powerpc architecture.
>=20
> As a temporary workaround I hacked the physmap_of driver to
> handle "direct-mapped" OF devices oh type "ram" by adding a
> corresponding entry in the of_flash_match[] array. This seems to work
> fine.=20
>=20
> What would be the preferred way to handle OF-compatible RAM-based MTD
> devices ? The 3 ways I can think of are
>=20
> 1. porting the plat-ram driver to OF (the driver isn't used
> in the kernel tree
> but I suspect it is used by out-of-tree boards)
>=20
> 2. creating a new plat-ram-of driver, much like the
> physmap_of driver comes
> from the physmap driver
>=20
> 3. extending the physmap_of driver to handle RAM devices (in
> which case
> references to "flash" in the function names should probably
> be replaced
> by "mtd")
>=20
> I live option 3 better so far.
>=20
> Has anyone already worked on this ? Is there any defined
> device tree mapping
> for MTD RAM devices ?
>=20
> Best regards,

We ran ito the same issue.=20
We did option 3, as it was efinetly the easiest,
here is the sram entry in our dts:

        sram@9,0 {
            device_type =3D "rom";
            compatible =3D "direct-mapped";
            probe-type =3D "RAM";
            reg =3D <9 0 20000>;
            bank-width =3D <2>;
            device-width =3D <2>;
            #address-cells =3D <1>;
            #size-cells =3D <1>;
            partition@0 {
                label =3D "SRAM";
                reg =3D <0 20000>;
            };

here is the change to physmap_of.c:

diff --git a/drivers/mtd/maps/physmap_of.c
b/drivers/mtd/maps/physmap_of.c
old mode 100644
new mode 100755
index aeed9ea..687ef54
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -201,6 +201,8 @@ static struct mtd_info * __devinit
obsolete_probe(struct of_device *dev,
 		return do_map_probe("cfi_probe", map);
 	} else if (strcmp(of_probe, "JEDEC") =3D=3D 0) {
 		return do_map_probe("jedec_probe", map);
+	} else if (strcmp(of_probe, "RAM") =3D=3D 0) {
+		return do_map_probe("map_ram", map);
 	} else {
 		if (strcmp(of_probe, "ROM") !=3D 0)
 			dev_warn(&dev->dev, "obsolete_probe: don't know
probe "

Re: OF compatible MTD platform RAM driver ?

[David Gibson]

On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:
> linuxppc-dev-bounces+runet=innovsys.com@ozlabs.org wrote:
> > Hi everybody,
> > 
> > as part of a ARCH=ppc to ARCH=powerpc migration process, I'm
> > looking for an
> > OpenFirmware compatible way to handle a RAM-based MTD device.
> > 
> > On the platform_device based ppc architecture, the
> > drivers/mtd/maps/plat-ram.c
> > driver handled "mtd-ram" platform devices. There is no such
> > driver for the
> > OF-based powerpc architecture.
> > 
> > As a temporary workaround I hacked the physmap_of driver to
> > handle "direct-mapped" OF devices oh type "ram" by adding a
> > corresponding entry in the of_flash_match[] array. This seems to work
> > fine. 
> > 
> > What would be the preferred way to handle OF-compatible RAM-based MTD
> > devices ? The 3 ways I can think of are
> > 
> > 1. porting the plat-ram driver to OF (the driver isn't used
> > in the kernel tree
> > but I suspect it is used by out-of-tree boards)
> > 
> > 2. creating a new plat-ram-of driver, much like the
> > physmap_of driver comes
> > from the physmap driver
> > 
> > 3. extending the physmap_of driver to handle RAM devices (in
> > which case
> > references to "flash" in the function names should probably
> > be replaced
> > by "mtd")
> > 
> > I live option 3 better so far.
> > 
> > Has anyone already worked on this ? Is there any defined
> > device tree mapping
> > for MTD RAM devices ?
> 
> 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.

> 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.

-- 
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

Re: OF compatible MTD platform RAM driver ?

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]

On Tuesday 11 March 2008 01:45, David Gibson wrote:
> On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:
> > linuxppc-dev-bounces+runet=innovsys.com@ozlabs.org wrote:
> > > Hi everybody,
> > >
> > > as part of a ARCH=ppc to ARCH=powerpc migration process, I'm
> > > looking for an
> > > OpenFirmware compatible way to handle a RAM-based MTD device.
> > >
> > > On the platform_device based ppc architecture, the
> > > drivers/mtd/maps/plat-ram.c
> > > driver handled "mtd-ram" platform devices. There is no such
> > > driver for the
> > > OF-based powerpc architecture.
> > >
> > > As a temporary workaround I hacked the physmap_of driver to
> > > handle "direct-mapped" OF devices oh type "ram" by adding a
> > > corresponding entry in the of_flash_match[] array. This seems to work
> > > fine.
> > >
> > > What would be the preferred way to handle OF-compatible RAM-based MTD
> > > devices ? The 3 ways I can think of are
> > >
> > > 1. porting the plat-ram driver to OF (the driver isn't used
> > > in the kernel tree
> > > but I suspect it is used by out-of-tree boards)
> > >
> > > 2. creating a new plat-ram-of driver, much like the
> > > physmap_of driver comes
> > > from the physmap driver
> > >
> > > 3. extending the physmap_of driver to handle RAM devices (in
> > > which case
> > > references to "flash" in the function names should probably
> > > be replaced
> > > by "mtd")
> > >
> > > I live option 3 better so far.
> > >
> > > Has anyone already worked on this ? Is there any defined
> > > device tree mapping
> > > for MTD RAM devices ?
> >
> > 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 ?

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: OF compatible MTD platform RAM driver ?

[Rune Torgersen]

David Gibson wrote:
> On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:
>> We ran ito the same issue.
>> We did option 3, as it was efinetly the easiest,
>=20
> I think this is the best option in principle.
>=20
>> here is the sram entry in our dts:
>=20
> Except that your implementation of it is not good.
>=20
> 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.

Yea, I know. But it was the easiest way of doing it at the time we did
our port....
In a timecrunch, easier is sometimes better than correct. :)

Re: OF compatible MTD platform RAM driver ?

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

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:
> > > linuxppc-dev-bounces+runet=innovsys.com@ozlabs.org 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.  Arguably RAM should be represented by a memory node, but
that's going to get messy for this sort of application.

-- 
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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: OF compatible MTD platform RAM driver ?

[David Gibson]

On Tue, Mar 11, 2008 at 10:00:10AM -0500, Rune Torgersen wrote:
> David Gibson wrote:
> > On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:
> >> 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.
> > 
> >> 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.
> 
> Yea, I know. But it was the easiest way of doing it at the time we did
> our port....
> In a timecrunch, easier is sometimes better than correct. :)

Well sure, but don't expect others to be swayed by your time pressure.

-- 
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

Re: OF compatible MTD platform RAM driver ?

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 2189 bytes --]

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:
> > > > linuxppc-dev-bounces+runet=innovsys.com@ozlabs.org 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 ?

        nvram@2,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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: OF compatible MTD platform RAM driver ?

[Sergei Shtylyov]

Hello.

Laurent Pinchart wrote:

>>>>>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 

    Yeah, and I can point you to it -- see the documantation section on 
http://www.openbios.org/...

> there any ROM binding in there ?

    No. We initially called the flash devices that physmap_of driver 
controlled "rom" (I mean the "device_type" property) -- now this is obsoleted.

>>Arguably RAM should be represented by a memory node, but 
>>that's going to get messy for this sort of application.

    Note that the OF "memory" type nodes do *not* represent RAM devices.

> 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 ?

>         nvram@2,0000 {

    Note that there's a OF "device_type" of "nvram", so your (generic) device 
name seems to add some mess. (IIRC, that OF device type didn't actually 
represent a "real" device, and only served to provide access to NVRAM for OF).

>                 compatible = "mtd,ram";

    The part before comma should be a company name or a stock ticker. What did 
you mean here?

>                 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 ?

    The "device_type" properties are not required and their further creation 
has been discouraged on liunxppc-dev.

> Best regards,

WBR, Sergei

Re: OF compatible MTD platform RAM driver ?

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]

Hi Sergei,

On Tuesday 25 March 2008 16:29, Sergei Shtylyov wrote:
> Hello.
> 
> Laurent Pinchart wrote:
> 
> >>>>>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 
> 
>     Yeah, and I can point you to it -- see the documantation section on 
> http://www.openbios.org/...

Thanks a lot for the pointer.

> > there any ROM binding in there ?
> 
>     No. We initially called the flash devices that physmap_of driver 
> controlled "rom" (I mean the "device_type" property) -- now this is obsoleted.
> 
> >>Arguably RAM should be represented by a memory node, but 
> >>that's going to get messy for this sort of application.
> 
>     Note that the OF "memory" type nodes do *not* represent RAM devices.
> 
> > 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 ?
> 
> >         nvram@2,0000 {
> 
>     Note that there's a OF "device_type" of "nvram", so your (generic) device 
> name seems to add some mess. (IIRC, that OF device type didn't actually 
> represent a "real" device, and only served to provide access to NVRAM for OF).

Ok.

> >                 compatible = "mtd,ram";
> 
>     The part before comma should be a company name or a stock ticker. What did 
> you mean here?

I didn't know that. Let's say I meant "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 ?
> 
>     The "device_type" properties are not required and their further creation 
> has been discouraged on liunxppc-dev.

What about

	mtdram@2,0000 {
		compatible = "mtd-ram";
		reg = <2 0x0000 0x00100000>;
		bank-width = <2>;
	};

ROMs could use "mtd-rom" for their compatible property.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: OF compatible MTD platform RAM driver ?

[Sergei Shtylyov]

Laurent Pinchart wrote:

>>>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 ?

>>>        nvram@2,0000 {

>>    Note that there's a OF "device_type" of "nvram", so your (generic) device 
>>name seems to add some mess. (IIRC, that OF device type didn't actually 
>>represent a "real" device, and only served to provide access to NVRAM for OF).

> Ok.

    Well, I might have gone too far here -- it should be a real device 
(spec'ed in Device Support Extensions recommended practice). It's just that 
the spec didn't mention "reg" property, only "#bytes" (the device capacity). 
So, it may be worth considering...

>>>                compatible = "mtd,ram";

>>    The part before comma should be a company name or a stock ticker. What did 
>>you mean here?

> I didn't know that. Let's say I meant "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 ?

>>    The "device_type" properties are not required and their further creation 
>>has been discouraged on liunxppc-dev.

> What about

> 	mtdram@2,0000 {
> 		compatible = "mtd-ram";
> 		reg = <2 0x0000 0x00100000>;
> 		bank-width = <2>;
> 	};

> ROMs could use "mtd-rom" for their compatible property.

    Heh, there was a whole company against mentioning "mtd" when we started 
working on this (of course, the first idea was to call the flash device type 
"mtd"). I don't think "mtd" looks good here -- I'd suggest "flash-ram" (if 
this is just a linearly mapped NVRAM).

> Best regards,

WBR, Sergei

Re: OF compatible MTD platform RAM driver ?

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]

On Tuesday 25 March 2008 17:23, Sergei Shtylyov wrote:
> Laurent Pinchart wrote:
> 
> >>>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 ?
> 
> >>>        nvram@2,0000 {
> 
> >>    Note that there's a OF "device_type" of "nvram", so your (generic) 
device 
> >>name seems to add some mess. (IIRC, that OF device type didn't actually 
> >>represent a "real" device, and only served to provide access to NVRAM for 
OF).
> 
> > Ok.
> 
>     Well, I might have gone too far here -- it should be a real device 
> (spec'ed in Device Support Extensions recommended practice). It's just that 
> the spec didn't mention "reg" property, only "#bytes" (the device capacity). 
> So, it may be worth considering...

The nvram device descrived in the Device Support Extensions is probably meant 
to describe the kind of nvram found in RTC chips. That memory isn't directly 
accessible. As the spec doesn't mention this explicitely we could still reuse 
the nvram device type for direct-mapped battery-backed ram. I have no strong 
opinion for or against that.

> >>>                compatible = "mtd,ram";
> 
> >>    The part before comma should be a company name or a stock ticker. What 
did 
> >>you mean here?
> 
> > I didn't know that. Let's say I meant "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 ?
> 
> >>    The "device_type" properties are not required and their further 
creation 
> >>has been discouraged on liunxppc-dev.
> 
> > What about
> 
> > 	mtdram@2,0000 {
> > 		compatible = "mtd-ram";
> > 		reg = <2 0x0000 0x00100000>;
> > 		bank-width = <2>;
> > 	};
> 
> > ROMs could use "mtd-rom" for their compatible property.
> 
>     Heh, there was a whole company against mentioning "mtd" when we started 
> working on this (of course, the first idea was to call the flash device type 
> "mtd"). I don't think "mtd" looks good here -- I'd suggest "flash-ram" (if 
> this is just a linearly mapped NVRAM).

I'm fine with "flash-ram" (even thought it looks a bit weird). I'll prepare a 
patch.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: OF compatible MTD platform RAM driver ?

[Sergei Shtylyov]

Laurent Pinchart wrote:

>>>>>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 ?

>>>>>       nvram@2,0000 {

>>>>   Note that there's a OF "device_type" of "nvram", so your (generic) device 
>>>>name seems to add some mess. (IIRC, that OF device type didn't actually 
>>>>represent a "real" device, and only served to provide access to NVRAM for OF).

>>>Ok.

>>    Well, I might have gone too far here -- it should be a real device 
>>(spec'ed in Device Support Extensions recommended practice). It's just that 
>>the spec didn't mention "reg" property, only "#bytes" (the device capacity). 
>>So, it may be worth considering...

> The nvram device descrived in the Device Support Extensions is probably meant 
> to describe the kind of nvram found in RTC chips.

    Well, that is only an assumption -- actually, the sentense in the 
description of the "#bytes" prop about the typical size being from 4 to 32K 
speaks against it. The details of NVRAM implementation are hidden behind 
read/write/seek methods.

> That memory isn't directly accessible.

    That's what we have a "compatible" prop for. ;-)

> As the spec doesn't mention this explicitely we could still reuse 
> the nvram device type for direct-mapped battery-backed ram. I have no strong 
> opinion for or against that.

>>>>>               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 ?

>>>>   The "device_type" properties are not required and their further creation 

>>>>has been discouraged on liunxppc-dev.

>>>What about

>>>	mtdram@2,0000 {
>>>		compatible = "mtd-ram";
>>>		reg = <2 0x0000 0x00100000>;
>>>		bank-width = <2>;
>>>	};

>>>ROMs could use "mtd-rom" for their compatible property.

>>    Heh, there was a whole company against mentioning "mtd" when we started 
>>working on this (of course, the first idea was to call the flash device type 
>>"mtd"). I don't think "mtd" looks good here -- I'd suggest "flash-ram" (if 
>>this is just a linearly mapped NVRAM).

> I'm fine with "flash-ram" (even thought it looks a bit weird). I'll prepare a 
> patch.

    Yeah. I forgeot that "flash" means EEPROM. Actually, the main facts about 
the NVRAM that I'd want to be stated in the "compatible" property is that it's 
non-volatile and directly/lineraly mapped... Just "nvram" doesn't seem 
enopugh, maybe "linear-nvram" is. And we can specify "device_type" of "nvram" 
indeed (and #size).

> Best regards,

WBR, Sergei

Re: OF compatible MTD platform RAM driver ?

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

On Tuesday 25 March 2008 18:02, Sergei Shtylyov wrote:
> Laurent Pinchart wrote:
> 
> > > Heh, there was a whole company against mentioning "mtd" when we started 
> > > working on this (of course, the first idea was to call the flash device
> > > type "mtd"). I don't think "mtd" looks good here -- I'd suggest
> > > "flash-ram" (if this is just a linearly mapped NVRAM).
> 
> > I'm fine with "flash-ram" (even thought it looks a bit weird). I'll
> > prepare a patch.
> 
> Yeah. I forgeot that "flash" means EEPROM. Actually, the main facts about 
> the NVRAM that I'd want to be stated in the "compatible" property is that
> it's  non-volatile and directly/lineraly mapped... Just "nvram" doesn't seem 
> enopugh, maybe "linear-nvram" is.

Direct mapping is a hard requirement for the nvram if we want to use it with 
the MTD subsystem. Regarding non-volatility nothing prevents a user from 
using a volatile RAM as an MTD device, but there's little point in doing so. 
Would it be acceptable for the "linear-nvram" specification not to include 
volatile RAM ? ROM chips would be excluded too. Is that an issue ?

> And we can specify "device_type" of "nvram" indeed (and #size). 

I suppose you meant #bytes.

What about sub-partitions support ? Nothing prevents RAM-based MTD devices 
from being partioned. Would it be acceptable to reference the CFI/JEDEC flash 
section in Documentation/powerpc/booting-without-of.txt in the description of 
the nvram node ?

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: OF compatible MTD platform RAM driver ?

[Sergei Shtylyov]

Laurent Pinchart wrote:

>>>>Heh, there was a whole company against mentioning "mtd" when we started 
>>>>working on this (of course, the first idea was to call the flash device
>>>>type "mtd"). I don't think "mtd" looks good here -- I'd suggest
>>>>"flash-ram" (if this is just a linearly mapped NVRAM).

>>>I'm fine with "flash-ram" (even thought it looks a bit weird). I'll
>>>prepare a patch.

>>Yeah. I forgeot that "flash" means EEPROM. Actually, the main facts about 
>>the NVRAM that I'd want to be stated in the "compatible" property is that
>>it's  non-volatile and directly/lineraly mapped... Just "nvram" doesn't seem 
>>enopugh, maybe "linear-nvram" is.

> Direct mapping is a hard requirement for the nvram if we want to use it with 
> the MTD subsystem.

    I thought we're currently talking about a driver controlling the directly 
mapped NVRAM.  The "compatible" property wouldn't allow us to specify the 
compatibility to *any* NVRAM since there could be no "least common 
denominator" driver anyway.

> Regarding non-volatility nothing prevents a user from 
> using a volatile RAM as an MTD device, but there's little point in doing so.

    Indeed, if just for testing... we could specify non-volatility as the 
device's prop, though...

> Would it be acceptable for the "linear-nvram" specification not to include 
> volatile RAM ? ROM chips would be excluded too. Is that an issue ?

    Well, I think we need a separate "compatible" prop for ROMs. Or we'll end 
up with the "compatible" being just "memory" with the memory "attributes" 
(R/O, N/V) being described by other "properties"... :-)

>>And we can specify "device_type" of "nvram" indeed (and #size). 

> I suppose you meant #bytes.

    Of course. :-)

> What about sub-partitions support ? Nothing prevents RAM-based MTD devices 

    Hm... I remember that the knowledge of MTD partitions turned me away from 
"nvram" device type when I started spec'ing the flash binding -- it's not 
uncommon to have a flash partition devoted to and labelled as "nvram". 
Therefore, that sole partition would have been a "nvram" device for OF...

> from being partioned. Would it be acceptable to reference the CFI/JEDEC flash 
> section in Documentation/powerpc/booting-without-of.txt in the description of 
> the nvram node ?

    I don't see why not.

> Best regards,

WBR, Sergei

RE: OF compatible MTD platform RAM driver ?

[Rune Torgersen]

Laurent Pinchart wrote:
> On Tuesday 25 March 2008 18:02, Sergei Shtylyov wrote:
>> Laurent Pinchart wrote:
>>=20
> Regarding non-volatility nothing prevents a user from using a=20
> volatile RAM as an MTD device, but there's little point in doing so.
> Would it be acceptable for the "linear-nvram" specification
> not to include > volatile RAM ? ROM chips would be excluded too. Is
that an issue ?

We actually use a volatile ram (SRAM) as an MTD device. We use it to
store info from bootloader and system specific values between resets.

Re: OF compatible MTD platform RAM driver ?

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]

On Tuesday 25 March 2008 18:56, Rune Torgersen wrote:
> Laurent Pinchart wrote:
> > On Tuesday 25 March 2008 18:02, Sergei Shtylyov wrote:
> >> Laurent Pinchart wrote:
> >> 
> > Regarding non-volatility nothing prevents a user from using a 
> > volatile RAM as an MTD device, but there's little point in doing so.
> > Would it be acceptable for the "linear-nvram" specification
> > not to include > volatile RAM ? ROM chips would be excluded too. Is
> that an issue ?
> 
> We actually use a volatile ram (SRAM) as an MTD device. We use it to
> store info from bootloader and system specific values between resets.

So we're left with two main options.

- Reusing the nvram device type from the Device Support Extensions. Volatile 
devices wouldn't be supported, and we'd need a separate device specification 
for linear-mapped volatile RAMs. I'm not very happy with that.

- Using another device node with a compatible value set to "linear-ram" (or 
something similar). This would support both volatile and non-volatile 
devices, and a property could be added to specify if the device is volatile 
or not.

I'd go for the second option, and I'd specify a "linear-rom" compatible value 
as well while we're at it.

Both volatile and non-volatile RAMs can be handled by the physmap_of MTD 
driver. They both use the same map probe type ("map_ram"). Volatility isn't 
handled there.

ROMs should be handled by the same driver and should use the "mtd_rom" map 
probe type.

As all those devices use the physmap_of MTD driver, what about 
using "physmap-ram" and "physmap-rom" as compatibility names ?

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: OF compatible MTD platform RAM driver ?

[Sergei Shtylyov]

Laurent Pinchart wrote:

>>>Regarding non-volatility nothing prevents a user from using a 
>>>volatile RAM as an MTD device, but there's little point in doing so.
>>>Would it be acceptable for the "linear-nvram" specification
>>>not to include > volatile RAM ? ROM chips would be excluded too. Is

>>that an issue ?

>>We actually use a volatile ram (SRAM) as an MTD device. We use it to
>>store info from bootloader and system specific values between resets.

> So we're left with two main options.

> - Reusing the nvram device type from the Device Support Extensions. Volatile 
> devices wouldn't be supported, and we'd need a separate device specification 
> for linear-mapped volatile RAMs. I'm not very happy with that.

> - Using another device node with a compatible value set to "linear-ram" (or 
> something similar). This would support both volatile and non-volatile 
> devices, and a property could be added to specify if the device is volatile 
> or not.

> I'd go for the second option, and I'd specify a "linear-rom" compatible value 
> as well while we're at it.

> Both volatile and non-volatile RAMs can be handled by the physmap_of MTD 
> driver. They both use the same map probe type ("map_ram"). Volatility isn't 
> handled there.

> ROMs should be handled by the same driver and should use the "mtd_rom" map 
> probe type.

    OK, let's go with it.

> As all those devices use the physmap_of MTD driver, what about 
> using "physmap-ram" and "physmap-rom" as compatibility names ?

    Heh, we've gone thru "physmap" before -- it was labelled Linux-specific 
name (well, I'd agree with that).

> Best regards,

WBR, Sergei

Re: OF compatible MTD platform RAM driver ?

[Segher Boessenkool]

> So we're left with two main options.
>
> - Reusing the nvram device type from the Device Support Extensions.

This wouldn't bring you anything.  A device_type is only used internally
by OF, to decide what device nodes support which OF programming model.
If you only have a flat device tree, "device_type" should be used only
as a workaround for older kernels that require it.

> - Using another device node with a compatible value set to 
> "linear-ram" (or
> something similar). This would support both volatile and non-volatile
> devices, and a property could be added to specify if the device is 
> volatile
> or not.

"memory-mapped-memory" perhaps :-)

Or, just "memory".  Although that one might play havoc with some
not-quite-correct main memory probing code.


Segher

Re: OF compatible MTD platform RAM driver ?

[Segher Boessenkool]

> The nvram device descrived in the Device Support Extensions is 
> probably meant
> to describe the kind of nvram found in RTC chips.

It describes a generic interface _within OF_ for _all kinds_ of NVRAM,
both physical and virtual.


Segher

Re: OF compatible MTD platform RAM driver ?

[Sergei Shtylyov]

Segher Boessenkool wrote:

>> - Using another device node with a compatible value set to 
>> "linear-ram" (or
>> something similar). This would support both volatile and non-volatile
>> devices, and a property could be added to specify if the device is 
>> volatile
>> or not.

> "memory-mapped-memory" perhaps :-)

> Or, just "memory".  Although that one might play havoc with some

    I'd suggest "ram" and "rom" then. Luckily the device trees don't contain 
binding for the real RAM chips yet. :-)

> not-quite-correct main memory probing code.

    You mean the there's parsers that search the "compatible" prop for 
"memory" as well as "device_type" prop?

> Segher

WBR, Sergei

Re: OF compatible MTD platform RAM driver ?

[Laurent Pinchart]

On Wednesday 26 March 2008 13:53, Sergei Shtylyov wrote:
> Laurent Pinchart wrote:
>=20
> >>>Regarding non-volatility nothing prevents a user from using a=20
> >>>volatile RAM as an MTD device, but there's little point in doing so.
> >>>Would it be acceptable for the "linear-nvram" specification
> >>>not to include > volatile RAM ? ROM chips would be excluded too. Is
>=20
> >>that an issue ?
>=20
> >>We actually use a volatile ram (SRAM) as an MTD device. We use it to
> >>store info from bootloader and system specific values between resets.
>=20
> > So we're left with two main options.
>=20
> > - Reusing the nvram device type from the Device Support Extensions.=20
Volatile=20
> > devices wouldn't be supported, and we'd need a separate device=20
specification=20
> > for linear-mapped volatile RAMs. I'm not very happy with that.
>=20
> > - Using another device node with a compatible value set to "linear-ram"=
=20
(or=20
> > something similar). This would support both volatile and non-volatile=20
> > devices, and a property could be added to specify if the device is=20
volatile=20
> > or not.
>=20
> > I'd go for the second option, and I'd specify a "linear-rom" compatible=
=20
value=20
> > as well while we're at it.
>=20
> > Both volatile and non-volatile RAMs can be handled by the physmap_of MT=
D=20
> > driver. They both use the same map probe type ("map_ram"). Volatility=20
isn't=20
> > handled there.
>=20
> > ROMs should be handled by the same driver and should use the "mtd_rom" =
map=20
> > probe type.
>=20
>     OK, let's go with it.
>=20
> > As all those devices use the physmap_of MTD driver, what about=20
> > using "physmap-ram" and "physmap-rom" as compatibility names ?
>=20
>     Heh, we've gone thru "physmap" before -- it was labelled Linux-specif=
ic=20
> name (well, I'd agree with that).

physmap stands for physically mapped. That doesn't sound Linux-specific to =
me,=20
the fact that the MTD driver has the same name is a pure coincidence.=20
linmap-rom and linmap-rom sound even more Linux-specific :-)

Could we agree on a name ? I'd like to submit a new patch.

=2D-=20
Laurent Pinchart
CSE Semaphore Belgium

Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
=46 +32 (2) 387 42 75

Re: OF compatible MTD platform RAM driver ?

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]

On Wednesday 26 March 2008 16:40, Sergei Shtylyov wrote:
> Segher Boessenkool wrote:
> 
> >> - Using another device node with a compatible value set to 
> >> "linear-ram" (or
> >> something similar). This would support both volatile and non-volatile
> >> devices, and a property could be added to specify if the device is 
> >> volatile
> >> or not.
> 
> > "memory-mapped-memory" perhaps :-)
> 
> > Or, just "memory".  Although that one might play havoc with some
> 
>     I'd suggest "ram" and "rom" then. Luckily the device trees don't contain 
> binding for the real RAM chips yet. :-)

And when it will we'll be in trouble.

Here are a few names. I like physmap-r[ao]m better. Does anyone have another 
suggestion ? I'd like to send a revised patch.

linear-r[ao]m
linear-mapped-r[ao]m
mapped-r[ao]m
memory-mapped-r[ao]m
physmap-r[ao]m

> > not-quite-correct main memory probing code.
> 
>     You mean the there's parsers that search the "compatible" prop for 
> "memory" as well as "device_type" prop?

-- 
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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: OF compatible MTD platform RAM driver ?

[David Gibson]

On Thu, Mar 27, 2008 at 10:13:32AM +0100, Laurent Pinchart wrote:
> On Wednesday 26 March 2008 13:53, Sergei Shtylyov wrote:
> > Laurent Pinchart wrote:
[snip]
> >     Heh, we've gone thru "physmap" before -- it was labelled Linux-specific 
> > name (well, I'd agree with that).
> 
> physmap stands for physically mapped. That doesn't sound
> Linux-specific to me, the fact that the MTD driver has the same name
> is a pure coincidence.  linmap-rom and linmap-rom sound even more
> Linux-specific :-)

It may not be Linux specific per se, but it's a bad name, because the
fact that the device is physically direct mapped isn't a useful
distinguishing feature of the device.  Main memory is also direct
physically mapped, after all, but that's not what you want to cover
with this description.  In general how a device is wired is described
by where it sits in the tree, not by its properties.

It only seems like a usefully distinguishing name because it's the
Linux "physmap_of" driver that uses it.  So in this sense it is a
Linux specific name after all.  In fact, physmap_of is itself very
badly named - right now it only handles direct mapped mtds, but that's
not inherent; it could be trivially extended to also instantiate a
non-direct-mapped device (as long as the underlying mtd layer
supported it, of course).  It bears no relation at all to the
"physmap" driver, except historical accident.

> Could we agree on a name ? I'd like to submit a new patch.

For ROMs I think just plain "rom" should be sufficient.  For RAMs we
need something to indicate that it's memory but intended for secondary
storage, not as main memory.  Unfortunately, I'm finding myself unable
to think of something.

-- 
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

Re: OF compatible MTD platform RAM driver ?

[Sergei Shtylyov]

Hello.

David Gibson wrote:

>>>Laurent Pinchart wrote:

> [snip]

>>>    Heh, we've gone thru "physmap" before -- it was labelled Linux-specific 
>>>name (well, I'd agree with that).

>>physmap stands for physically mapped. That doesn't sound
>>Linux-specific to me, the fact that the MTD driver has the same name
>>is a pure coincidence.  linmap-rom and linmap-rom sound even more
>>Linux-specific :-)

> It may not be Linux specific per se, but it's a bad name, because the
> fact that the device is physically direct mapped isn't a useful
> distinguishing feature of the device.

    Yeah, it's not a propery of a device itself (yet, the device would be 
useless if this information is not supplied in the tree somehow). Yet remember 
the now ungoing discussion about "reg-shift" property for UARTs -- some people 
said that the fact that this property may not be a feature of device is 
irrelevant WRT the binding. :-)

> Main memory is also direct physically mapped, after all,  but that's not what you want to cover
> with this description.

   Haven't ever seen the description of memory as a device (unless you mean 
the "memory" node which can hardly be considered proper device -- mainly 
because of their usual placement at the top of the tree, and not where a RAM 
device logically should be in the bus hierarchy).

> In general how a device is wired is described by where it sits in the tree, not by its properties.

    Oh, another argument against "reg-shift" in the Xilinx UART quarry... :-)

> It only seems like a usefully distinguishing name because it's the
> Linux "physmap_of" driver that uses it.  So in this sense it is a
> Linux specific name after all.  In fact, physmap_of is itself very
> badly named - right now it only handles direct mapped mtds, but that's

    Yeah, because that's what is what it has been written for.

> not inherent; it could be trivially extended to also instantiate a
> non-direct-mapped device (as long as the underlying mtd layer
> supported it, of course).   It bears no relation at all to the
 > "physmap" driver, except historical accident.

    This driver resides on the "top", device mapping layer of the MTD 
hierarchy, and I don't see a point of cramming support for all the possible 
mappings into one driver vs doing it as the *separate* specific drivers in 
drivers/mtd/mapps/ -- as it has been done in the MTD tree before "the great OF 
revolution". This is really strange idea...

WBR, Sergei

Re: OF compatible MTD platform RAM driver ?

[Laurent Pinchart]

On Thursday 27 March 2008 11:03, David Gibson wrote:
> On Thu, Mar 27, 2008 at 10:13:32AM +0100, Laurent Pinchart wrote:
> > On Wednesday 26 March 2008 13:53, Sergei Shtylyov wrote:
> > > Laurent Pinchart wrote:
> [snip]
> > >     Heh, we've gone thru "physmap" before -- it was labelled
> > >     Linux-specific name (well, I'd agree with that).
> >=20
> > physmap stands for physically mapped. That doesn't sound
> > Linux-specific to me, the fact that the MTD driver has the same name
> > is a pure coincidence.  linmap-rom and linmap-rom sound even more
> > Linux-specific :-)
>=20
> It may not be Linux specific per se, but it's a bad name, because the
> fact that the device is physically direct mapped isn't a useful
> distinguishing feature of the device.  Main memory is also direct
> physically mapped, after all, but that's not what you want to cover
> with this description.  In general how a device is wired is described
> by where it sits in the tree, not by its properties.
>=20
> It only seems like a usefully distinguishing name because it's the
> Linux "physmap_of" driver that uses it.  So in this sense it is a
> Linux specific name after all.  In fact, physmap_of is itself very
> badly named - right now it only handles direct mapped mtds, but that's
> not inherent; it could be trivially extended to also instantiate a
> non-direct-mapped device (as long as the underlying mtd layer
> supported it, of course).  It bears no relation at all to the
> "physmap" driver, except historical accident.
>=20
> > Could we agree on a name ? I'd like to submit a new patch.
>=20
> For ROMs I think just plain "rom" should be sufficient.  For RAMs we
> need something to indicate that it's memory but intended for secondary
> storage, not as main memory.  Unfortunately, I'm finding myself unable
> to think of something.

What about "storage-ram", "auxiliary-ram", "secondary-ram", "application-ra=
m",
"user-ram" or "ramdisk" ?

=2D-=20
Laurent Pinchart
CSE Semaphore Belgium

Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
=46 +32 (2) 387 42 75

Re: OF compatible MTD platform RAM driver ?

[David Gibson]

On Thu, Mar 27, 2008 at 03:23:46PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> David Gibson wrote:
>
>>>> Laurent Pinchart wrote:
>
>> [snip]
>
>>>>    Heh, we've gone thru "physmap" before -- it was labelled 
>>>> Linux-specific name (well, I'd agree with that).
>
>>> physmap stands for physically mapped. That doesn't sound
>>> Linux-specific to me, the fact that the MTD driver has the same name
>>> is a pure coincidence.  linmap-rom and linmap-rom sound even more
>>> Linux-specific :-)
>
>> It may not be Linux specific per se, but it's a bad name, because the
>> fact that the device is physically direct mapped isn't a useful
>> distinguishing feature of the device.
>
>    Yeah, it's not a propery of a device itself (yet, the device would be 
> useless if this information is not supplied in the tree somehow). Yet 
> remember the now ungoing discussion about "reg-shift" property for UARTs -- 
> some people said that the fact that this property may not be a feature of 
> device is irrelevant WRT the binding. :-)
>
>> Main memory is also direct physically mapped, after all,  but that's not 
>> what you want to cover
>> with this description.
>
>   Haven't ever seen the description of memory as a device (unless you mean 
> the "memory" node which can hardly be considered proper device -- mainly 
> because of their usual placement at the top of the tree, and not where a 
> RAM device logically should be in the bus hierarchy).

Yes, I mean the memory node.  And although it's no very likely,
there's no inherent reason a RAM device couldn't also be at the top of
the tree, on a CPU with the right sort of localbus.

>> In general how a device is wired is described by where it sits in the 
>> tree, not by its properties.
>
>    Oh, another argument against "reg-shift" in the Xilinx UART quarry... 
> :-)

Not really.  I was perhaps a bit strong, wiring information in the
properties isn't necessarily wrong, but it does need a close look.
"reg-shift" is a useful compromise.

>> It only seems like a usefully distinguishing name because it's the
>> Linux "physmap_of" driver that uses it.  So in this sense it is a
>> Linux specific name after all.  In fact, physmap_of is itself very
>> badly named - right now it only handles direct mapped mtds, but that's
>
>    Yeah, because that's what is what it has been written for.
>
>> not inherent; it could be trivially extended to also instantiate a
>> non-direct-mapped device (as long as the underlying mtd layer
>> supported it, of course).   It bears no relation at all to the
> > "physmap" driver, except historical accident.
>
>    This driver resides on the "top", device mapping layer of the MTD 
> hierarchy, and I don't see a point of cramming support for all the possible 
> mappings into one driver vs doing it as the *separate* specific drivers in 
> drivers/mtd/mapps/

Because doing it as separate drivers would mean duplicating most of
physmap_of for absolutely no reason.  I'll say it again there is
*nothing* that actually relies on the direct mapping in physmap_of;
the *only* thing it does is take the device tree information and
marshal it into an initialization call for the appropriate mtd chip
drivers.

I really should get around to sending a patch to rename physmap_of to
"of_mtd.c".

> -- as it has been done in the MTD tree before "the great 
> OF revolution". This is really strange idea...

The only reason mtd needs heaps of little "map drivers" (which barely
deserve the title of "driver") is because there wasn't a single
generally available source of information about where and how flash
was mapped so a whole pile of platform or sitation specific ways of
getting that information were needed.  With a device tree all that can
be replaced with just getting the information from the device tree.

-- 
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

Re: OF compatible MTD platform RAM driver ?

[David Gibson]

On Thu, Mar 27, 2008 at 03:31:34PM +0100, Laurent Pinchart wrote:
> On Thursday 27 March 2008 11:03, David Gibson wrote:
> > On Thu, Mar 27, 2008 at 10:13:32AM +0100, Laurent Pinchart wrote:
> > > On Wednesday 26 March 2008 13:53, Sergei Shtylyov wrote:
> > > > Laurent Pinchart wrote:
> > [snip]
> > > >     Heh, we've gone thru "physmap" before -- it was labelled
> > > >     Linux-specific name (well, I'd agree with that).
> > > 
> > > physmap stands for physically mapped. That doesn't sound
> > > Linux-specific to me, the fact that the MTD driver has the same name
> > > is a pure coincidence.  linmap-rom and linmap-rom sound even more
> > > Linux-specific :-)
> > 
> > It may not be Linux specific per se, but it's a bad name, because the
> > fact that the device is physically direct mapped isn't a useful
> > distinguishing feature of the device.  Main memory is also direct
> > physically mapped, after all, but that's not what you want to cover
> > with this description.  In general how a device is wired is described
> > by where it sits in the tree, not by its properties.
> > 
> > It only seems like a usefully distinguishing name because it's the
> > Linux "physmap_of" driver that uses it.  So in this sense it is a
> > Linux specific name after all.  In fact, physmap_of is itself very
> > badly named - right now it only handles direct mapped mtds, but that's
> > not inherent; it could be trivially extended to also instantiate a
> > non-direct-mapped device (as long as the underlying mtd layer
> > supported it, of course).  It bears no relation at all to the
> > "physmap" driver, except historical accident.
> > 
> > > Could we agree on a name ? I'd like to submit a new patch.
> > 
> > For ROMs I think just plain "rom" should be sufficient.  For RAMs we
> > need something to indicate that it's memory but intended for secondary
> > storage, not as main memory.  Unfortunately, I'm finding myself unable
> > to think of something.
> 
> What about "storage-ram", "auxiliary-ram", "secondary-ram",
> "application-ram", "user-ram" or "ramdisk" ?

Well, I like all those better than anything previously suggested.
"storage-ram" is probably my favourite.  It still doesn't seem great,
but given I've been unable to thing of something better.

-- 
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

Re: OF compatible MTD platform RAM driver ?

[Sergei Shtylyov]

David Gibson wrote:

>>>>>   Heh, we've gone thru "physmap" before -- it was labelled 
>>>>>Linux-specific name (well, I'd agree with that).

>>>>physmap stands for physically mapped. That doesn't sound
>>>>Linux-specific to me, the fact that the MTD driver has the same name
>>>>is a pure coincidence.  linmap-rom and linmap-rom sound even more
>>>>Linux-specific :-)

>>>It may not be Linux specific per se, but it's a bad name, because the
>>>fact that the device is physically direct mapped isn't a useful
>>>distinguishing feature of the device.

>>   Yeah, it's not a propery of a device itself (yet, the device would be 
>>useless if this information is not supplied in the tree somehow). Yet 
>>remember the now ungoing discussion about "reg-shift" property for UARTs -- 
>>some people said that the fact that this property may not be a feature of 
>>device is irrelevant WRT the binding. :-)

>>>Main memory is also direct physically mapped, after all,  but that's not 
>>>what you want to cover
>>>with this description.

>>  Haven't ever seen the description of memory as a device (unless you mean 
>>the "memory" node which can hardly be considered proper device -- mainly 
>>because of their usual placement at the top of the tree, and not where a 
>>RAM device logically should be in the bus hierarchy).

> Yes, I mean the memory node.  And although it's no very likely,
> there's no inherent reason a RAM device couldn't also be at the top of
> the tree, on a CPU with the right sort of localbus.

    Yeah, according to the spec. this represents a RAM device. Too bad it's 
too often misplaced in the tree being on the top layer, and creating confusion 
(I used to misplace MTD device because of that)... :-(

>>>In general how a device is wired is described by where it sits in the 
>>>tree, not by its properties.

>>   Oh, another argument against "reg-shift" in the Xilinx UART quarry... 
>>:-)

> Not really.  I was perhaps a bit strong, wiring information in the
> properties isn't necessarily wrong, but it does need a close look.
> "reg-shift" is a useful compromise.

    And I've heard it's been spec'ed already. :-)
    And MTD could surely a subject to alike compromise since it can be wired 
to the bus in a weird way too (not very likely though).

>>>not inherent; it could be trivially extended to also instantiate a
>>>non-direct-mapped device (as long as the underlying mtd layer
>>>supported it, of course).   It bears no relation at all to the
>>>"physmap" driver, except historical accident.

>>   This driver resides on the "top", device mapping layer of the MTD 

    Which is actually bottom of course call-wise since it reads/writes the 
actual data for the upper layers.

>>hierarchy, and I don't see a point of cramming support for all the possible 
>>mappings into one driver vs doing it as the *separate* specific drivers in 
>>drivers/mtd/mapps/

> Because doing it as separate drivers would mean duplicating most of
> physmap_of for absolutely no reason.  I'll say it again there is

    Duplicating what, device probe/remove code? Partition parsing has been at 
last factored out into separate module by somebody (that patch should be 
queued in the MTD tree though I'm not sure), the old probing/partition code 
(i.e. our lame one) is not needed for the newly added devices...

> *nothing* that actually relies on the direct mapping in physmap_of;

    Really? Even simple_map_init() call it does?

> the *only* thing it does is take the device tree information and
> marshal it into an initialization call for the appropriate mtd chip
> drivers.

    No, not only that...

> I really should get around to sending a patch to rename physmap_of to
> "of_mtd.c".

    I don't think you should bother with that.

>>-- as it has been done in the MTD tree before "the great 
>>OF revolution". This is really strange idea...

> The only reason mtd needs heaps of little "map drivers" (which barely
> deserve the title of "driver")

    It's a layered driver structure

> is because there wasn't a single
> generally available source of information about where and how flash
> was mapped

    Not entirely true. You could try passing extra info with the platform 
device information...

> so a whole pile of platform or sitation specific ways of
> getting that information were needed.

    Some drivers read the h/w registers to determine the right type of mapping 
-- well, this probably could be replaced with reading this info from the 
device tree...

> With a device tree all that can
> be replaced with just getting the information from the device tree.

    Don't forget that such a universal driver would be taking extra kernel 
memory space as well, being loaded with the unused code handling all known 
mappings as well as extra probe/remove code...

WBR, Sergei

Re: OF compatible MTD platform RAM driver ?

[Segher Boessenkool]

>> "memory-mapped-memory" perhaps :-)
>
>> Or, just "memory".  Although that one might play havoc with some
>
>    I'd suggest "ram" and "rom" then. Luckily the device trees don't 
> contain binding for the real RAM chips yet. :-)
>
>> not-quite-correct main memory probing code.
>
>    You mean the there's parsers that search the "compatible" prop for 
> "memory" as well as "device_type" prop?

There are parsers that make all kinds of mistakes, sure.

The code that figures out what region of ram to use should look at the
node pointed to by /chosen/memory, it's shouldn't look for anything
with a certain "compatible", and it shouldn't look at "device_type"
_at all_.


Segher

Re: OF compatible MTD platform RAM driver ?

[Segher Boessenkool]

>> Could we agree on a name ? I'd like to submit a new patch.
>
> For ROMs I think just plain "rom" should be sufficient.

Yes.

> For RAMs we
> need something to indicate that it's memory but intended for secondary
> storage, not as main memory.

How it is intended to be used is not a property of the hardware, so
that information doesn't belong in the device tree at all.  The Linux
platform code should handle this, I imagine.


Segher

Re: OF compatible MTD platform RAM driver ?

[Paul Mackerras]

Segher Boessenkool writes:

> > For RAMs we
> > need something to indicate that it's memory but intended for secondary
> > storage, not as main memory.
> 
> How it is intended to be used is not a property of the hardware, so
> that information doesn't belong in the device tree at all.  The Linux
> platform code should handle this, I imagine.

There must be some reason why it is not intended to be used as main
memory.  Presumably it has something different about it compared to
"normal" RAM, and that difference could perfectly well be expressed in
the device tree.

Paul.

Re: OF compatible MTD platform RAM driver ?

[Segher Boessenkool]

>>> For RAMs we
>>> need something to indicate that it's memory but intended for 
>>> secondary
>>> storage, not as main memory.
>>
>> How it is intended to be used is not a property of the hardware, so
>> that information doesn't belong in the device tree at all.  The Linux
>> platform code should handle this, I imagine.
>
> There must be some reason why it is not intended to be used as main
> memory.  Presumably it has something different about it compared to
> "normal" RAM, and that difference could perfectly well be expressed in
> the device tree.

Sure, that's a different thing.  It might sit on a bus that doesn't
do cache coherency, or maybe it's just slow (or sits on a slow bus).
All these things can be usefully expressed in the device tree (but
typically are not, it is left to the client code to know this stuff
implicitly).

It's still the (platform) probe code its responsibility to figure
out what (if anything) to do with any device.  And "main memory"
is probed differently (via /chosen/memory, for example) anyway.
Well, actually, Linux searches for all nodes with device_type "memory",
which should work fine as well [*].

So, all in all, I think we should just give these "auxiliary memory"
devices a name of "ram" c.q. "rom", and some "reg", and that should
be all that is needed: the main memory probe stuff won't consider
these nodes, and the (platform) device probe code can do whatever it
wants (create mtd devices, I guess).


Segher


[*] It seems to me the longtrail workaround code in prom_init.c is
incorrect though: it will match any node with name "memory" that
doesn't have a device_type?

Re: OF compatible MTD platform RAM driver ?

[Paul Mackerras]

Segher Boessenkool writes:

> It's still the (platform) probe code its responsibility to figure
> out what (if anything) to do with any device.  And "main memory"
> is probed differently (via /chosen/memory, for example) anyway.
> Well, actually, Linux searches for all nodes with device_type "memory",
> which should work fine as well [*].
> 
> So, all in all, I think we should just give these "auxiliary memory"
> devices a name of "ram" c.q. "rom", and some "reg", and that should
> be all that is needed: the main memory probe stuff won't consider
> these nodes, and the (platform) device probe code can do whatever it
> wants (create mtd devices, I guess).

Sounds reasonable.

> [*] It seems to me the longtrail workaround code in prom_init.c is
> incorrect though: it will match any node with name "memory" that
> doesn't have a device_type?

It only matches on children of the root node, and it's that way
because the /memory node in the longtrail device tree doesn't have a
device_type.  Actually we could probably remove the longtrail stuff
now; I think mine has stopped working, and I only know of 2 others in
existence. :)

Paul.

Re: OF compatible MTD platform RAM driver ?

[Segher Boessenkool]

>> [*] It seems to me the longtrail workaround code in prom_init.c is
>> incorrect though: it will match any node with name "memory" that
>> doesn't have a device_type?
>
> It only matches on children of the root node,

Oh okay, I misread that then.

> and it's that way
> because the /memory node in the longtrail device tree doesn't have a
> device_type.

Yeah.

> Actually we could probably remove the longtrail stuff
> now; I think mine has stopped working, and I only know of 2 others in
> existence. :)

I'll prepare a patch.


Segher

Re: OF compatible MTD platform RAM driver ?

[Segher Boessenkool]

[Removed linux-mtd from cc:]

>>> [*] It seems to me the longtrail workaround code in prom_init.c is
>>> incorrect though: it will match any node with name "memory" that
>>> doesn't have a device_type?
>>
>> It only matches on children of the root node,
>
> Oh okay, I misread that then.

...No, I did not.  prom_next_node() does a depth-first tree traversal.

>> Actually we could probably remove the longtrail stuff
>> now; I think mine has stopped working, and I only know of 2 others in
>> existence. :)
>
> I'll prepare a patch.

...Actually, that's a lot of code to rip out, and I can't test this at 
all,
so I'll have to pass on this.


Segher

Re: OF compatible MTD platform RAM driver ?

[Laurent Pinchart]

On Monday 31 March 2008 00:39, Segher Boessenkool wrote:
> >>> For RAMs we
> >>> need something to indicate that it's memory but intended for=20
> >>> secondary
> >>> storage, not as main memory.
> >>
> >> How it is intended to be used is not a property of the hardware, so
> >> that information doesn't belong in the device tree at all.  The Linux
> >> platform code should handle this, I imagine.
> >
> > There must be some reason why it is not intended to be used as main
> > memory.  Presumably it has something different about it compared to
> > "normal" RAM, and that difference could perfectly well be expressed in
> > the device tree.
>=20
> Sure, that's a different thing.  It might sit on a bus that doesn't
> do cache coherency, or maybe it's just slow (or sits on a slow bus).
> All these things can be usefully expressed in the device tree (but
> typically are not, it is left to the client code to know this stuff
> implicitly).
>=20
> It's still the (platform) probe code its responsibility to figure
> out what (if anything) to do with any device.  And "main memory"
> is probed differently (via /chosen/memory, for example) anyway.
> Well, actually, Linux searches for all nodes with device_type "memory",
> which should work fine as well [*].
>=20
> So, all in all, I think we should just give these "auxiliary memory"
> devices a name of "ram" c.q. "rom", and some "reg", and that should
> be all that is needed: the main memory probe stuff won't consider
> these nodes, and the (platform) device probe code can do whatever it
> wants (create mtd devices, I guess).

Ok, I get your point. I'll prepare a new documentation patch; changes to=20
physmap_of.c will go away.

If I understand you correctly, there should be no "compatible" property on =
the=20
ram and rom devices. Should the "non-volatile", "slow" and "static ram"=20
properties still be expressed in the device tree ?

=2D-=20
Laurent Pinchart
CSE Semaphore Belgium

Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
=46 +32 (2) 387 42 75

Re: OF compatible MTD platform RAM driver ?

[Segher Boessenkool]

>> So, all in all, I think we should just give these "auxiliary memory"
>> devices a name of "ram" c.q. "rom", and some "reg", and that should
>> be all that is needed: the main memory probe stuff won't consider
>> these nodes, and the (platform) device probe code can do whatever it
>> wants (create mtd devices, I guess).
>
> Ok, I get your point. I'll prepare a new documentation patch; changes 
> to
> physmap_of.c will go away.

Thanks.

> If I understand you correctly, there should be no "compatible" 
> property on the
> ram and rom devices.

They aren't normally needed here, I think.

> Should the "non-volatile", "slow" and "static ram"
> properties still be expressed in the device tree ?

If those are useful.  I'll need to see a proposed binding to form
an opinion on this, it's too vague now, sorry.


Segher