[PATCH v3 3/4] powerpc: NAND: FSL UPM: document new bindings

[Grant Likely]

(cc'ing devicetree-discuss)

On Wed, Mar 25, 2009 at 4:08 AM, Wolfgang Grandegger <wg at grandegger.com> wrote:
> This patch adds documentation for the new NAND FSL UPM bindings for:
>
>  NAND: FSL-UPM: add multi chip support
>  NAND: FSL-UPM: Add wait flags to support board/chip specific delays
>
> Signed-off-by: Wolfgang Grandegger <wg at grandegger.com>

Mostly looks good to me; but some comments below.

> ---
>  .../powerpc/dts-bindings/fsl/upm-nand.txt          |   39 +++++++++++++++++++-
>  1 files changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt b/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
> index 84a04d5..0272e70 100644
> --- a/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
> +++ b/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt
> @@ -5,9 +5,22 @@ Required properties:
>  - reg : should specify localbus chip select and size used for the chip.
>  - fsl,upm-addr-offset : UPM pattern offset for the address latch.
>  - fsl,upm-cmd-offset : UPM pattern offset for the command latch.
> -- gpios : may specify optional GPIO connected to the Ready-Not-Busy pin.
>
> -Example:
> +Optional properties:
> +- fsl,upm-wait-flags : add chip-dependent short delays after running the
> +                      UPM pattern (0x1), after writing a data byte (0x2)
> +                      or after writing out a buffer (0x4).
> +- gpios : may specify optional GPIOs connected to the Ready-Not-Busy pins
> +         (R/B#). For multi-chip devices, "num-chips" GPIO definitions are
> +         required.
> +- chip-delay : chip dependent delay for transfering data from array to
> +              read registers (tR). Required if property "gpios" is not
> +              used (R/B# pins not connected).
> +- num-chips : number of chips per device for multi-chip support.
> +- chip-offset : address offset between chips for multi-chip support. The
> +               corresponding address lines are used to select the chip.

Since these properties (chip-delay, num-chips and chip-offset) are
currently controller specific, it would probably be a good idea to
prefix 'fsl,' onto them.  That way when common NAND controller
properties start getting defined then there won't be any concern about
conflicting with existing meanings.  If you do see these as properties
that other NAND controllers will use, then maybe a 'nand-' prefix is
appropriate (like the SPI binding in booting-without-of).

For the chip offset, it's not clear what the meaning is.  First, does
the UPM controller support access of multiple chips simultaneously?
If so, then can you elaborate in the description on how board design
translates to a chip-offset value.  If it cannot, then it might be
better to have multiple tuples in the 'reg' property for each discrete
chip.  Multiple reg tuples would also remove the need for the
num-chips property.

Cheers,
g.

> +
> +Examples:
>
>  upm at 1,0 {
>        compatible = "fsl,upm-nand";
> @@ -26,3 +39,25 @@ upm at 1,0 {
>                };
>        };
>  };
> +
> +upm at 3,0 {
> +       compatible = "fsl,upm-nand";
> +       reg = <3 0x0 0x800>;
> +       fsl,upm-addr-offset = <0x10>;
> +       fsl,upm-cmd-offset = <0x08>;
> +       fsl,upm-wait-flags = <0x5>;
> +       /* Multi-chip device */
> +       num-chips = <2>;
> +       chip-offset = <0x200>;
> +       chip-delay = <25>; // in micro-seconds
> +
> +       nand at 0 {
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +
> +               partition at 0 {
> +                           label = "fs";
> +                           reg = <0x00000000 0x10000000>;
> +               };
> +       };
> +};
> --
> 1.6.0.6
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>



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