[PATCH] mtd/maps: add mtd-ram support to physmap_of

[PATCH] mtd/maps: add mtd-ram support to physmap_of

[Wolfram Sang]

Use physmap_of to access RAMs as mtd and add documenation for it. This approach
is a lot less intrusive as adding an of-wrapper around plat-ram.c. As most
extensions of plat-ram.c (e.g. custom map-functions) can't be mapped to the
device tree anyhow, extending physmap_of seems to be the cleanest approach.

Tested with a phyCORE-MPC5121e.

Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Vitaly Wool <vwool@ru.mvista.com>
Cc: Artem Bityutskiy <dedekind@infradead.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ken MacLeod <ken@bitsko.slc.ut.us>
Cc: Albrecht Dreß <albrecht.dress@arcor.de>
---
 Documentation/powerpc/dts-bindings/mtd-physmap.txt |   42 ++++++++++++-------
 drivers/mtd/maps/physmap_of.c                      |    4 ++
 2 files changed, 30 insertions(+), 16 deletions(-)

diff --git a/Documentation/powerpc/dts-bindings/mtd-physmap.txt b/Documentation/powerpc/dts-bindings/mtd-physmap.txt
index 667c9bd..80152cb 100644
--- a/Documentation/powerpc/dts-bindings/mtd-physmap.txt
+++ b/Documentation/powerpc/dts-bindings/mtd-physmap.txt
@@ -1,18 +1,19 @@
-CFI or JEDEC memory-mapped NOR flash
+CFI or JEDEC memory-mapped NOR flash, MTD-RAM (NVRAM...)
 
 Flash chips (Memory Technology Devices) are often used for solid state
 file systems on embedded devices.
 
- - compatible : should contain the specific model of flash chip(s)
-   used, if known, followed by either "cfi-flash" or "jedec-flash"
- - reg : Address range(s) of the flash chip(s)
+ - compatible : should contain the specific model of mtd chip(s)
+   used, if known, followed by either "cfi-flash", "jedec-flash"
+   or "mtd-ram".
+ - reg : Address range(s) of the mtd chip(s)
    It's possible to (optionally) define multiple "reg" tuples so that
-   non-identical NOR chips can be described in one flash node.
- - bank-width : Width (in bytes) of the flash bank.  Equal to the
+   non-identical chips can be described in one node.
+ - bank-width : Width (in bytes) of the bank.  Equal to the
    device width times the number of interleaved chips.
- - device-width : (optional) Width of a single flash chip.  If
+ - device-width : (optional) Width of a single mtd chip.  If
    omitted, assumed to be equal to 'bank-width'.
- - #address-cells, #size-cells : Must be present if the flash has
+ - #address-cells, #size-cells : Must be present if the device has
    sub-nodes representing partitions (see below).  In this case
    both #address-cells and #size-cells must be equal to 1.
 
@@ -22,24 +23,24 @@ are defined:
  - vendor-id : Contains the flash chip's vendor id (1 byte).
  - device-id : Contains the flash chip's device id (1 byte).
 
-In addition to the information on the flash bank itself, the
+In addition to the information on the mtd bank itself, the
 device tree may optionally contain additional information
-describing partitions of the flash address space.  This can be
+describing partitions of the address space.  This can be
 used on platforms which have strong conventions about which
-portions of the flash are used for what purposes, but which don't
+portions of a flash are used for what purposes, but which don't
 use an on-flash partition table such as RedBoot.
 
-Each partition is represented as a sub-node of the flash device.
+Each partition is represented as a sub-node of the mtd device.
 Each node's name represents the name of the corresponding
-partition of the flash device.
+partition of the mtd device.
 
 Flash partitions
- - reg : The partition's offset and size within the flash bank.
- - label : (optional) The label / name for this flash partition.
+ - reg : The partition's offset and size within the mtd bank.
+ - label : (optional) The label / name for this partition.
    If omitted, the label is taken from the node name (excluding
    the unit address).
  - read-only : (optional) This parameter, if present, is a hint to
-   Linux that this flash partition should only be mounted
+   Linux that this partition should only be mounted
    read-only.  This is usually used for flash partitions
    containing early-boot firmware images or data which should not
    be clobbered.
@@ -78,3 +79,12 @@ Here an example with multiple "reg" tuples:
 			reg = <0 0x04000000>;
 		};
 	};
+
+An example using SRAM:
+
+	sram@2,0 {
+		compatible = "samsung,k6f1616u6a", "mtd-ram";
+		reg = <2 0 0x00200000>;
+		bank-width = <2>;
+	};
+
diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index 39d357b..45eee20 100644
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -360,6 +360,10 @@ static struct of_device_id of_flash_match[] = {
 		.data		= (void *)"jedec_probe",
 	},
 	{
+		.compatible     = "mtd-ram",
+		.data           = (void *)"map_ram",
+	},
+	{
 		.type		= "rom",
 		.compatible	= "direct-mapped"
 	},
-- 
1.6.3.1

Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of

[Albrecht Dreß]

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

Am 17.07.09 14:39 schrieb(en) Wolfram Sang:
> Use physmap_of to access RAMs as mtd and add documenation for it.  
> This approach is a lot less intrusive as adding an of-wrapper around  
> plat-ram.c. As most extensions of plat-ram.c (e.g. custom  
> map-functions) can't be mapped to the device tree anyhow, extending  
> physmap_of seems to be the cleanest approach.

The patch works nicely on a custom (roughly Icecube) based 5200B board,  
with a Renesas static ram, no partitions and a jffs2 file system on  
it.  I had to add some more tweaks to physmap_of.c as to work around  
the 5200's limitations accessing chips in 16-bit mode through the local  
bus, which is a lot easier and cleaner with this patch than with the  
old one (of 05 June 09).

Acked-by: Albrecht Dreß <albrecht.dress@arcor.de>

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

Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of

[Grant Likely]

On Fri, Jul 17, 2009 at 6:39 AM, Wolfram Sang<w.sang@pengutronix.de> wrote:
> Use physmap_of to access RAMs as mtd and add documenation for it. This ap=
proach
> is a lot less intrusive as adding an of-wrapper around plat-ram.c. As mos=
t
> extensions of plat-ram.c (e.g. custom map-functions) can't be mapped to t=
he
> device tree anyhow, extending physmap_of seems to be the cleanest approac=
h.
>
> Tested with a phyCORE-MPC5121e.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>

Looks good to me.

Acked-by: Grant Likely <grant.likely@secretlab.ca>

> Cc: Vitaly Wool <vwool@ru.mvista.com>
> Cc: Artem Bityutskiy <dedekind@infradead.org>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Ken MacLeod <ken@bitsko.slc.ut.us>
> Cc: Albrecht Dre=DF <albrecht.dress@arcor.de>
> ---
> =A0Documentation/powerpc/dts-bindings/mtd-physmap.txt | =A0 42 ++++++++++=
++-------
> =A0drivers/mtd/maps/physmap_of.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0| =A0 =A04 ++
> =A02 files changed, 30 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/powerpc/dts-bindings/mtd-physmap.txt b/Documen=
tation/powerpc/dts-bindings/mtd-physmap.txt
> index 667c9bd..80152cb 100644
> --- a/Documentation/powerpc/dts-bindings/mtd-physmap.txt
> +++ b/Documentation/powerpc/dts-bindings/mtd-physmap.txt
> @@ -1,18 +1,19 @@
> -CFI or JEDEC memory-mapped NOR flash
> +CFI or JEDEC memory-mapped NOR flash, MTD-RAM (NVRAM...)
>
> =A0Flash chips (Memory Technology Devices) are often used for solid state
> =A0file systems on embedded devices.
>
> - - compatible : should contain the specific model of flash chip(s)
> - =A0 used, if known, followed by either "cfi-flash" or "jedec-flash"
> - - reg : Address range(s) of the flash chip(s)
> + - compatible : should contain the specific model of mtd chip(s)
> + =A0 used, if known, followed by either "cfi-flash", "jedec-flash"
> + =A0 or "mtd-ram".
> + - reg : Address range(s) of the mtd chip(s)
> =A0 =A0It's possible to (optionally) define multiple "reg" tuples so that
> - =A0 non-identical NOR chips can be described in one flash node.
> - - bank-width : Width (in bytes) of the flash bank. =A0Equal to the
> + =A0 non-identical chips can be described in one node.
> + - bank-width : Width (in bytes) of the bank. =A0Equal to the
> =A0 =A0device width times the number of interleaved chips.
> - - device-width : (optional) Width of a single flash chip. =A0If
> + - device-width : (optional) Width of a single mtd chip. =A0If
> =A0 =A0omitted, assumed to be equal to 'bank-width'.
> - - #address-cells, #size-cells : Must be present if the flash has
> + - #address-cells, #size-cells : Must be present if the device has
> =A0 =A0sub-nodes representing partitions (see below). =A0In this case
> =A0 =A0both #address-cells and #size-cells must be equal to 1.
>
> @@ -22,24 +23,24 @@ are defined:
> =A0- vendor-id : Contains the flash chip's vendor id (1 byte).
> =A0- device-id : Contains the flash chip's device id (1 byte).
>
> -In addition to the information on the flash bank itself, the
> +In addition to the information on the mtd bank itself, the
> =A0device tree may optionally contain additional information
> -describing partitions of the flash address space. =A0This can be
> +describing partitions of the address space. =A0This can be
> =A0used on platforms which have strong conventions about which
> -portions of the flash are used for what purposes, but which don't
> +portions of a flash are used for what purposes, but which don't
> =A0use an on-flash partition table such as RedBoot.
>
> -Each partition is represented as a sub-node of the flash device.
> +Each partition is represented as a sub-node of the mtd device.
> =A0Each node's name represents the name of the corresponding
> -partition of the flash device.
> +partition of the mtd device.
>
> =A0Flash partitions
> - - reg : The partition's offset and size within the flash bank.
> - - label : (optional) The label / name for this flash partition.
> + - reg : The partition's offset and size within the mtd bank.
> + - label : (optional) The label / name for this partition.
> =A0 =A0If omitted, the label is taken from the node name (excluding
> =A0 =A0the unit address).
> =A0- read-only : (optional) This parameter, if present, is a hint to
> - =A0 Linux that this flash partition should only be mounted
> + =A0 Linux that this partition should only be mounted
> =A0 =A0read-only. =A0This is usually used for flash partitions
> =A0 =A0containing early-boot firmware images or data which should not
> =A0 =A0be clobbered.
> @@ -78,3 +79,12 @@ Here an example with multiple "reg" tuples:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0 0x04000000>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
> =A0 =A0 =A0 =A0};
> +
> +An example using SRAM:
> +
> + =A0 =A0 =A0 sram@2,0 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "samsung,k6f1616u6a", "mtd-r=
am";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <2 0 0x00200000>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 bank-width =3D <2>;
> + =A0 =A0 =A0 };
> +
> diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.=
c
> index 39d357b..45eee20 100644
> --- a/drivers/mtd/maps/physmap_of.c
> +++ b/drivers/mtd/maps/physmap_of.c
> @@ -360,6 +360,10 @@ static struct of_device_id of_flash_match[] =3D {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.data =A0 =A0 =A0 =A0 =A0 =3D (void *)"jed=
ec_probe",
> =A0 =A0 =A0 =A0},
> =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 .compatible =A0 =A0 =3D "mtd-ram",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 .data =A0 =A0 =A0 =A0 =A0 =3D (void *)"map_=
ram",
> + =A0 =A0 =A0 },
> + =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.type =A0 =A0 =A0 =A0 =A0 =3D "rom",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.compatible =A0 =A0 =3D "direct-mapped"
> =A0 =A0 =A0 =A0},
> --
> 1.6.3.1
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev



--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of

[Artem Bityutskiy]

On Fri, 2009-08-07 at 23:43 -0600, Grant Likely wrote:
> On Fri, Jul 17, 2009 at 6:39 AM, Wolfram Sang<w.sang@pengutronix.de> wrote:
> > Use physmap_of to access RAMs as mtd and add documenation for it. This approach
> > is a lot less intrusive as adding an of-wrapper around plat-ram.c. As most
> > extensions of plat-ram.c (e.g. custom map-functions) can't be mapped to the
> > device tree anyhow, extending physmap_of seems to be the cleanest approach.
> >
> > Tested with a phyCORE-MPC5121e.
> >
> > Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> 
> Looks good to me.
> 
> Acked-by: Grant Likely <grant.likely@secretlab.ca>

This patch is sitting in my l2-mtd-2.6.git tree.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of

[Wolfram Sang]

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

On Sun, Aug 09, 2009 at 08:17:23AM +0300, Artem Bityutskiy wrote:
> On Fri, 2009-08-07 at 23:43 -0600, Grant Likely wrote:
> > On Fri, Jul 17, 2009 at 6:39 AM, Wolfram Sang<w.sang@pengutronix.de> wrote:
> > > Use physmap_of to access RAMs as mtd and add documenation for it. This approach
> > > is a lot less intrusive as adding an of-wrapper around plat-ram.c. As most
> > > extensions of plat-ram.c (e.g. custom map-functions) can't be mapped to the
> > > device tree anyhow, extending physmap_of seems to be the cleanest approach.
> > >
> > > Tested with a phyCORE-MPC5121e.
> > >
> > > Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> > 
> > Looks good to me.
> > 
> > Acked-by: Grant Likely <grant.likely@secretlab.ca>
> 
> This patch is sitting in my l2-mtd-2.6.git tree.

Great, thanks a lot (and for your l2-tree in general!). One question: Are the
additional Acked-bys added later? I could think they might be useful for
David's review...

Kind regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

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

Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of

[Artem Bityutskiy]

On Mon, 2009-08-10 at 18:19 +0200, Wolfram Sang wrote:
> On Sun, Aug 09, 2009 at 08:17:23AM +0300, Artem Bityutskiy wrote:
> > On Fri, 2009-08-07 at 23:43 -0600, Grant Likely wrote:
> > > On Fri, Jul 17, 2009 at 6:39 AM, Wolfram Sang<w.sang@pengutronix.de> wrote:
> > > > Use physmap_of to access RAMs as mtd and add documenation for it. This approach
> > > > is a lot less intrusive as adding an of-wrapper around plat-ram.c. As most
> > > > extensions of plat-ram.c (e.g. custom map-functions) can't be mapped to the
> > > > device tree anyhow, extending physmap_of seems to be the cleanest approach.
> > > >
> > > > Tested with a phyCORE-MPC5121e.
> > > >
> > > > Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> > > 
> > > Looks good to me.
> > > 
> > > Acked-by: Grant Likely <grant.likely@secretlab.ca>
> > 
> > This patch is sitting in my l2-mtd-2.6.git tree.
> 
> Great, thanks a lot (and for your l2-tree in general!). One question: Are the
> additional Acked-bys added later? I could think they might be useful for
> David's review...

Well, I do not bother maintaining nice history there, so rebase it
freely, which means I can add your ack. Will do tomorrow.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of

[Artem Bityutskiy]

On 08/10/2009 07:19 PM, Wolfram Sang wrote:
> On Sun, Aug 09, 2009 at 08:17:23AM +0300, Artem Bityutskiy wrote:
>> On Fri, 2009-08-07 at 23:43 -0600, Grant Likely wrote:
>>> On Fri, Jul 17, 2009 at 6:39 AM, Wolfram Sang<w.sang@pengutronix.de>  wrote:
>>>> Use physmap_of to access RAMs as mtd and add documenation for it. This approach
>>>> is a lot less intrusive as adding an of-wrapper around plat-ram.c. As most
>>>> extensions of plat-ram.c (e.g. custom map-functions) can't be mapped to the
>>>> device tree anyhow, extending physmap_of seems to be the cleanest approach.
>>>>
>>>> Tested with a phyCORE-MPC5121e.
>>>>
>>>> Signed-off-by: Wolfram Sang<w.sang@pengutronix.de>
>>> Looks good to me.
>>>
>>> Acked-by: Grant Likely<grant.likely@secretlab.ca>
>> This patch is sitting in my l2-mtd-2.6.git tree.
>
> Great, thanks a lot (and for your l2-tree in general!). One question: Are the
> additional Acked-bys added later? I could think they might be useful for
> David's review...

Added Acked-by: Grant Likely<grant.likely@secretlab.ca>

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)