OF compatible MTD platform RAM driver ?

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

3 more lines

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

1 more quoted lines

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 "

On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:

linuxppc-dev-bounces+runet=innovsys.com@ozlabs.org wrote:

quoted

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 ?

3 more quoted lines

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

On Tuesday 11 March 2008 01:45, David Gibson wrote:

On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:

quoted

linuxppc-dev-bounces+runet=innovsys.com@ozlabs.org wrote:

quoted

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

6 more quoted lines

I'll implement that and post a patch after completing the ppc-to-powerpc 
migration.

quoted

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

David Gibson wrote:

On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:

quoted

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

quoted

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

On Tue, Mar 11, 2008 at 11:39:08AM +0100, Laurent Pinchart wrote:

On Tuesday 11 March 2008 01:45, David Gibson wrote:

quoted

On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:

quoted

linuxppc-dev-bounces+runet=innovsys.com@ozlabs.org wrote:

[snip]

quoted

quoted

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.

quoted

quoted

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

On Tue, Mar 11, 2008 at 10:00:10AM -0500, Rune Torgersen wrote:

David Gibson wrote:

quoted

On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:

quoted

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.

quoted

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

On Tuesday 11 March 2008 23:40, David Gibson wrote:

On Tue, Mar 11, 2008 at 11:39:08AM +0100, Laurent Pinchart wrote:

quoted

On Tuesday 11 March 2008 01:45, David Gibson wrote:

quoted

On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:

quoted

linuxppc-dev-bounces+runet=innovsys.com@ozlabs.org wrote:

[snip]

quoted

quoted

quoted

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.

quoted

quoted

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

Hello.

Laurent Pinchart wrote:

quoted

quoted

quoted

quoted

here is the sram entry in our dts:

quoted

quoted

quoted

Except that your implementation of it is not good.

quoted

quoted

quoted

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.

quoted

quoted

What "compatible" values should I use for ROM and RAM mappings ?

quoted

That I'm not so sure of.  We'll need to find some consensus.

quoted

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.

quoted

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

Hi Sergei,

On Tuesday 25 March 2008 16:29, Sergei Shtylyov wrote:

Hello.

Laurent Pinchart wrote:

quoted

quoted

quoted

quoted

quoted

here is the sram entry in our dts:

quoted

quoted

quoted

quoted

Except that your implementation of it is not good.

quoted

quoted

quoted

quoted

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.

quoted

quoted

quoted

What "compatible" values should I use for ROM and RAM mappings ?

quoted

quoted

That I'm not so sure of.  We'll need to find some consensus.

quoted

quoted

There may be existing IEEE1275 bindings for roms, which we should
investigate.

quoted

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.

quoted

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.

quoted

quoted

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.

quoted

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.

quoted

What about the following definition for the RAM node ?

quoted

        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.

quoted

                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" :-)

quoted

                reg = <2 0x0000 0x00100000>;
                bank-width = <2>;
        };

quoted

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

Laurent Pinchart wrote:

quoted

quoted

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.

quoted

quoted

What about the following definition for the RAM node ?

quoted

quoted

       nvram@2,0000 {

quoted

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

quoted

quoted

               compatible = "mtd,ram";

quoted

   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" :-)

quoted

quoted

               reg = <2 0x0000 0x00100000>;
               bank-width = <2>;
       };

quoted

quoted

Or should the node have a device-type property of either 'ram' or 'rom' with the compatible property just referencing MTD ?

quoted

   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

On Tuesday 25 March 2008 17:23, Sergei Shtylyov wrote:

Laurent Pinchart wrote:

quoted

quoted

quoted

We're talking about a very specific type of RAM, used for permanent 

storage 

quoted

quoted

quoted

with a battery backup. The RAM is really meant to be used as an MTD 

device 

quoted

quoted

quoted

and as such I think it makes sense to describe it as an mtd-compatible 

device 

quoted

quoted

quoted

on the local bus.

quoted

quoted

quoted

What about the following definition for the RAM node ?

quoted

quoted

quoted

       nvram@2,0000 {

quoted

quoted

   Note that there's a OF "device_type" of "nvram", so your (generic) 

device 

quoted

quoted

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

quoted

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.

quoted

quoted

quoted

               compatible = "mtd,ram";

quoted

quoted

   The part before comma should be a company name or a stock ticker. What 

did 

quoted

quoted

you mean here?

quoted

I didn't know that. Let's say I meant "mtd-ram" :-)

quoted

quoted

quoted

               reg = <2 0x0000 0x00100000>;
               bank-width = <2>;
       };

quoted

quoted

quoted

Or should the node have a device-type property of either 'ram' or 'rom' 

with 

quoted

quoted

quoted

the compatible property just referencing MTD ?

quoted

quoted

   The "device_type" properties are not required and their further 

creation 

quoted

quoted

has been discouraged on liunxppc-dev.

quoted

What about

quoted

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

quoted

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

Laurent Pinchart wrote:

quoted

quoted

quoted

quoted

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.

quoted

quoted

quoted

quoted

What about the following definition for the RAM node ?

quoted

quoted

quoted

quoted

      nvram@2,0000 {

quoted

quoted

quoted

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

quoted

quoted

Ok.

quoted

   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.

quoted

quoted

quoted

quoted

              reg = <2 0x0000 0x00100000>;
              bank-width = <2>;
      };

quoted

quoted

quoted

quoted

Or should the node have a device-type property of either 'ram' or 'rom' with the compatible property just referencing MTD ?

quoted

quoted

quoted

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

quoted

quoted

quoted

has been discouraged on liunxppc-dev.

quoted

quoted

What about

quoted

quoted

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

quoted

quoted

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

quoted

   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

On Tuesday 25 March 2008 18:02, Sergei Shtylyov wrote:

Laurent Pinchart wrote:

quoted

quoted

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

quoted

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

Laurent Pinchart wrote:

quoted

quoted

quoted

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

quoted

quoted

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

quoted

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"... :-)

quoted

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

Laurent Pinchart wrote:

On Tuesday 25 March 2008 18:02, Sergei Shtylyov wrote:

quoted

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.

On Tuesday 25 March 2008 18:56, Rune Torgersen wrote:

Laurent Pinchart wrote:

quoted

On Tuesday 25 March 2008 18:02, Sergei Shtylyov wrote:

quoted

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

Laurent Pinchart wrote:

quoted

quoted

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

quoted

that an issue ?

quoted

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

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

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

Segher Boessenkool wrote:

quoted

- 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

On Wednesday 26 March 2008 13:53, Sergei Shtylyov wrote:

Laurent Pinchart wrote:
=20

quoted

quoted

quoted

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

quoted

quoted

that an issue ?

=20

quoted

quoted

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

quoted

So we're left with two main options.

=20

quoted

- Reusing the nvram device type from the Device Support Extensions.=20

Volatile=20

quoted

devices wouldn't be supported, and we'd need a separate device=20

specification=20

quoted

for linear-mapped volatile RAMs. I'm not very happy with that.

=20

quoted

- Using another device node with a compatible value set to "linear-ram"=

=20
(or=20

quoted

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

quoted

or not.

=20

quoted

I'd go for the second option, and I'd specify a "linear-rom" compatible=

=20
value=20

quoted

as well while we're at it.

=20

quoted

Both volatile and non-volatile RAMs can be handled by the physmap_of MT=

D=20

quoted

driver. They both use the same map probe type ("map_ram"). Volatility=20

isn't=20

quoted

handled there.

=20

quoted

ROMs should be handled by the same driver and should use the "mtd_rom" =

map=20

quoted

probe type.

=20
    OK, let's go with it.
=20

quoted

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

On Wednesday 26 March 2008 16:40, Sergei Shtylyov wrote:

Segher Boessenkool wrote:

quoted

quoted

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

quoted

"memory-mapped-memory" perhaps :-)

quoted

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

quoted

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

On Thu, Mar 27, 2008 at 10:13:32AM +0100, Laurent Pinchart wrote:

On Wednesday 26 March 2008 13:53, Sergei Shtylyov wrote:

quoted

Laurent Pinchart wrote:

[snip]

quoted

    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

Hello.

David Gibson wrote:

quoted

quoted

Laurent Pinchart wrote:

[snip]

quoted

quoted

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

quoted

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

On Thursday 27 March 2008 11:03, David Gibson wrote:

On Thu, Mar 27, 2008 at 10:13:32AM +0100, Laurent Pinchart wrote:

quoted

On Wednesday 26 March 2008 13:53, Sergei Shtylyov wrote:

quoted

Laurent Pinchart wrote:

[snip]

quoted

quoted

    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

quoted

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

On Thu, Mar 27, 2008 at 03:23:46PM +0300, Sergei Shtylyov wrote:

Hello.

David Gibson wrote:

quoted

quoted

quoted

Laurent Pinchart wrote:

quoted

[snip]

quoted

quoted

quoted

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

quoted

quoted

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

quoted

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

quoted

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.

quoted

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.

quoted

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.

quoted

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

On Thu, Mar 27, 2008 at 03:31:34PM +0100, Laurent Pinchart wrote:

On Thursday 27 March 2008 11:03, David Gibson wrote:

quoted

On Thu, Mar 27, 2008 at 10:13:32AM +0100, Laurent Pinchart wrote:

quoted

On Wednesday 26 March 2008 13:53, Sergei Shtylyov wrote:

quoted

Laurent Pinchart wrote:

[snip]

quoted

quoted

    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.

quoted

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

David Gibson wrote:

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

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

quoted

quoted

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.

quoted

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

quoted

quoted

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

quoted

 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)... :-(

quoted

quoted

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

quoted

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

quoted

quoted

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.

quoted

  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.

quoted

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.

quoted

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

quoted

"memory-mapped-memory" perhaps :-)

quoted

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

quoted

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

quoted

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

Segher Boessenkool writes:

quoted

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.

quoted

quoted

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?

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.

quoted

[*] 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

[Removed linux-mtd from cc:]

quoted

quoted

[*] 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.

quoted

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

On Monday 31 March 2008 00:39, Segher Boessenkool wrote:

quoted

quoted

quoted

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

quoted

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