Re: [PATCH 3/6] tegra: fdt: Add NAND controller binding and definitions

[Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]

On 01/13/2012 04:10 PM, Simon Glass wrote:
> Add a NAND controller along with a bindings file for review.

A few questions to start with:

> diff --git a/doc/device-tree-bindings/nand/nvidia-nand.txt b/doc/device-tree-bindings/nand/nvidia-nand.txt

> +NAND Flash
> +----------
> +
> +(there isn't yet a generic binding in Linux, so this describes what is in
> +U-Boot)
> +
> +The device node for a NAND flash device is as described in the document
> +"Open Firmware Recommended Practice : Universal Serial Bus" with the
> +following modifications and additions :
> +
> +Required properties :
> + - compatible : Should be "manufacture,device", "nand-flash"
> + - page-data-bytes : Number of bytes in the data area
> + - page-spare-bytes : * Number of bytes in spare area
> +       spare area = skipped-spare-bytes + data-ecc-bytes + tag-bytes
> +			+ tag-ecc-bytes
> + - skipped-spare-bytes : Number of bytes to skip at start of spare area
> +	(these are typically used for bad block maintenance)
> + - data-ecc-bytes : Number of ECC bytes for data area
> + - tag-bytes :Number of tag bytes in spare area
> + - tag-ecc-bytes : Number ECC bytes to be generated for tag bytes

Are any of those values really needed?

I looked through all the NAND references I could find in the Linux
kernel in arch/*/boot/dts/* and none of them seem to have this kind of
information.

Looking at the drivers, they execute some form of identification command
on the NAND device which gives back a device ID, which is then looked up
in a table of known devices to give the information above.

I checked the Tegra NAND driver that's in the kernel chromeos-3.0
branch, and it does the same thing, albeit it open-codes some of the
identification routines rather than just calling into the common code.

Judging by arch/*/boot/dts/*, it is standard practice to have a node for
the NAND device itself though; it's used to house (optional) partition
definitions. In the kernel,
Documentation/devicetree/bindings/mtd/mtd-physmap.txt discusses the
format of these partition nodes, and e.g.
arch/powerpc/boot/dts/canyonlands.dts (amongst many) uses this on NAND.

> +Nvidia NAND Controller
> +----------------------
> +
> +The device node for a NAND flash controller is as described in the document
> +"Open Firmware Recommended Practice : Universal Serial Bus" with the
> +following modifications and additions :
> +
> +Optional properties:
> +
> +wp-gpio : GPIO of write-protect line, three cells in the format:
> +		phandle, parameter, flags
> +width : bus width of the NAND device in bits
> +
> +For now here is something specific to the Nvidia controller, with naming
> +based on Nvidia's original (non-fdt) NAND driver:
> +
> + - nvidia,nand-timing : Timing parameters for the NAND. Each is in ns.
> +	Order is: MAX_TRP_TREA, TWB, Max(tCS, tCH, tALS, tALH),
> +	TWHR, Max(tCS, tCH, tALS, tALH), TWH, TWP, TRH, TADL
> +
> +	MAX_TRP_TREA is:
> +		non-EDO mode: Max(tRP, tREA) + 6ns
> +		EDO mode: tRP timing

At first glance, it seems reasonable to have this in the NAND node; it's
certainly impossible to probe the timing parameters. Since NAND is so
standardized though, I wonder if there is a standard set of timing
parameters so that we could have a standard device tree binding for this?

> +Example:
> +
> +nand-controller@0x70008000 {
> +	compatible = "nvidia,tegra20-nand";
> +	wp-gpios = <&gpio 59 0>;		/* PH3 */
> +	width = <8>;
> +	nvidia,timing = <26 100 20 80 20 10 12 10 70>;
> +	nand@0 {
> +		compatible = "hynix,hy27uf4g2b", "nand-flash";
> +		page-data-bytes = <2048>;
> +		tag-ecc-bytes = <4>;
> +		tag-bytes = <20>;
> +		data-ecc-bytes = <36>;
> +		skipped-spare-bytes = <4>;
> +		page-spare-bytes = <64>;
> +	};
> +};

-- 
nvpublic