Devicetree
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: devicetree-discuss@ozlabs.org,
	"Vitaly Wool" <vwool@ru.mvista.com>,
	"Artem Bityutskiy" <dedekind@infradead.org>,
	"Albrecht Dreß" <albrecht.dress@arcor.de>,
	linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
	"Ken MacLeod" <ken@bitsko.slc.ut.us>,
	"David Woodhouse" <dwmw2@infradead.org>
Subject: Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of
Date: Fri, 7 Aug 2009 23:43:32 -0600	[thread overview]
Message-ID: <fa686aa40908072243x56d2160fk688149f4b7b912ae@mail.gmail.com> (raw)
In-Reply-To: <1247834363-28198-1-git-send-email-w.sang@pengutronix.de>

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>

> 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
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev



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

  parent reply	other threads:[~2009-08-08  5:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-17 12:39 [PATCH] mtd/maps: add mtd-ram support to physmap_of Wolfram Sang
     [not found] ` <1247834363-28198-1-git-send-email-w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2009-07-31 19:47   ` Albrecht Dreß
2009-08-08  5:43 ` Grant Likely [this message]
2009-08-09  5:17   ` Artem Bityutskiy
2009-08-10 16:19     ` Wolfram Sang
     [not found]       ` <20090810161942.GA27833-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2009-08-10 16:25         ` Artem Bityutskiy
2009-08-11  5:55       ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fa686aa40908072243x56d2160fk688149f4b7b912ae@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=albrecht.dress@arcor.de \
    --cc=dedekind@infradead.org \
    --cc=devicetree-discuss@ozlabs.org \
    --cc=dwmw2@infradead.org \
    --cc=ken@bitsko.slc.ut.us \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=vwool@ru.mvista.com \
    --cc=w.sang@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox