[PATCH 0/3] Add device-tree aware NDFC driver

[PATCH 0/3] Add device-tree aware NDFC driver

[Valentine Barshak]

This adds a device-tree aware PowerPC 44x NanD Flash Controller driver
The code is based on the original NDFC driver by Thomas Gleixner, but
since it's been changed much and has initialization/clean-up completely
reworked it's been put into a separate ndfc_of.c file. This version
supports both separate mtd devices on each chip attached to NDFC banks and
single mtd device spread across identical chips (not using mtdconcat) as well.
The choice is selected with device tree settings. This has been tested
on PowerPC 440EPx Sequoia board.
Any comments are greatly appreciated.
Thanks,
Valentine.

[PATCH 1/3] PowerPC: Add device-tree aware PowerPC 44x NDFC driver

[Valentine Barshak]

This adds support of the built-in PowerPC 44x NanD Flash Controller (NDFC)
based on the OF description. This version supports both separate mtd devices on
each NDFC bank and mtd devices spread across identical chips attached to NDFC
banks depending on the device tree settings. This is based on the original NDFC
driver by Thomas Gleixner, but since a lot of things have been reworked it's
been put to a separate ndfc_of file.

Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
 drivers/mtd/nand/Kconfig   |    7 
 drivers/mtd/nand/Makefile  |    1 
 drivers/mtd/nand/ndfc_of.c |  599 +++++++++++++++++++++++++++++++++++++++++++++
 include/linux/mtd/ndfc.h   |    4 
 4 files changed, 611 insertions(+)

diff -pruN linux-2.6.orig/drivers/mtd/nand/Kconfig linux-2.6/drivers/mtd/nand/Kconfig
--- linux-2.6.orig/drivers/mtd/nand/Kconfig	2007-10-29 16:02:37.000000000 +0300
+++ linux-2.6/drivers/mtd/nand/Kconfig	2007-10-29 19:02:13.000000000 +0300
@@ -158,6 +158,13 @@ config MTD_NAND_NDFC
 	help
 	 NDFC Nand Flash Controllers are integrated in IBM/AMCC's 4xx SoCs
 
+config MTD_NAND_NDFC_OF
+	tristate "NDFC NanD Flash Controller based on OF"
+	depends on 44x && PPC_MERGE
+	select MTD_NAND_ECC_SMC
+	help
+	 NDFC Nand Flash Controllers are integrated in EP44x SoCs
+
 config MTD_NAND_S3C2410_CLKSTOP
 	bool "S3C2410 NAND IDLE clock stop"
 	depends on MTD_NAND_S3C2410
diff -pruN linux-2.6.orig/drivers/mtd/nand/Makefile linux-2.6/drivers/mtd/nand/Makefile
--- linux-2.6.orig/drivers/mtd/nand/Makefile	2007-10-29 16:02:37.000000000 +0300
+++ linux-2.6/drivers/mtd/nand/Makefile	2007-10-29 18:59:11.000000000 +0300
@@ -24,6 +24,7 @@ obj-$(CONFIG_MTD_NAND_TS7250)		+= ts7250
 obj-$(CONFIG_MTD_NAND_NANDSIM)		+= nandsim.o
 obj-$(CONFIG_MTD_NAND_CS553X)		+= cs553x_nand.o
 obj-$(CONFIG_MTD_NAND_NDFC)		+= ndfc.o
+obj-$(CONFIG_MTD_NAND_NDFC_OF)		+= ndfc_of.o
 obj-$(CONFIG_MTD_NAND_AT91)		+= at91_nand.o
 obj-$(CONFIG_MTD_NAND_CM_X270)		+= cmx270_nand.o
 obj-$(CONFIG_MTD_NAND_BASLER_EXCITE)	+= excite_nandflash.o
diff -pruN linux-2.6.orig/drivers/mtd/nand/ndfc_of.c linux-2.6/drivers/mtd/nand/ndfc_of.c
--- linux-2.6.orig/drivers/mtd/nand/ndfc_of.c	1970-01-01 03:00:00.000000000 +0300
+++ linux-2.6/drivers/mtd/nand/ndfc_of.c	2007-10-29 22:07:45.000000000 +0300
@@ -0,0 +1,598 @@
+/*
+ *  Overview:
+ *   Platform independend driver for NDFC (NanD Flash Controller)
+ *   integrated into EP440 cores with OF device tree support
+ *
+ *  Based on the original ndfc driver by Thomas Gleixner
+ *
+ *  Copyright 2006 IBM
+ *
+ *  This program is free software; you can redistribute	 it and/or modify it
+ *  under  the terms of	 the GNU General  Public License as published by the
+ *  Free Software Foundation;  either version 2 of the	License, or (at your
+ *  option) any later version.
+ */
+#include <linux/module.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/nand_ecc.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/ndfc.h>
+#include <linux/mtd/mtd.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+
+#include <asm/io.h>
+
+
+struct of_ndfc {
+	__iomem void		*base;
+	struct resource		*res;
+	uint32_t		bank_mask;
+	struct nand_hw_control	control;
+	struct list_head	list;
+};
+
+struct of_ndfc_mtd {
+	struct list_head	list;
+	struct of_ndfc		*ndfc;
+	unsigned char		banks[NDFC_MAX_BANKS];
+	unsigned 		chip_cnt;
+	struct nand_chip	chip;
+	struct mtd_info		mtd;
+#ifdef CONFIG_MTD_PARTITIONS
+	struct mtd_partition	*parts;
+#endif
+};
+
+static inline u32 ndfc_raw_readl(struct of_ndfc *ndfc, u32 off)
+{
+	return __raw_readl(ndfc->base + off);
+}
+
+static inline void ndfc_raw_writel(struct of_ndfc *ndfc, u32 off, u32 val)
+{
+	__raw_writel(val, ndfc->base + off);
+}
+
+static inline void ndfc_writel(struct of_ndfc *ndfc, u32 off, u32 val)
+{
+	writel(val, ndfc->base + off);
+}
+
+static void ndfc_select_chip(struct mtd_info *mtd, int chip)
+{
+	struct nand_chip *this = mtd->priv;
+	struct of_ndfc_mtd *ndfc_mtd = this->priv;
+	struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+	uint32_t ccr;
+
+	ccr = ndfc_raw_readl(ndfc, NDFC_CCR);
+	if ((chip >= 0) && (chip < ndfc_mtd->chip_cnt))  {
+		ccr &= ~NDFC_CCR_BS_MASK;
+		ccr |= NDFC_CCR_BS(ndfc_mtd->banks[chip]);
+	} else
+		ccr |= NDFC_CCR_RESET_CE;
+	ndfc_raw_writel(ndfc, NDFC_CCR, ccr);
+}
+
+static void ndfc_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
+{
+	struct nand_chip *this = mtd->priv;
+	struct of_ndfc_mtd *ndfc_mtd = this->priv;
+	struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+
+	if (cmd == NAND_CMD_NONE)
+		return;
+
+	if (ctrl & NAND_CLE)
+		ndfc_writel(ndfc, NDFC_CMD, cmd & 0xff);
+	else
+		ndfc_writel(ndfc, NDFC_ALE, cmd & 0xff);
+}
+
+static int ndfc_ready(struct mtd_info *mtd)
+{
+	struct nand_chip *this = mtd->priv;
+	struct of_ndfc_mtd *ndfc_mtd = this->priv;
+	struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+
+	return ndfc_raw_readl(ndfc, NDFC_STAT) & NDFC_STAT_IS_READY;
+}
+
+static void ndfc_enable_hwecc(struct mtd_info *mtd, int mode)
+{
+	struct nand_chip *this = mtd->priv;
+	struct of_ndfc_mtd *ndfc_mtd = this->priv;
+	struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+	uint32_t ccr;
+
+	ccr = ndfc_raw_readl(ndfc, NDFC_CCR);
+	ccr |= NDFC_CCR_RESET_ECC;
+	ndfc_raw_writel(ndfc, NDFC_CCR, ccr);
+	wmb();
+}
+
+
+static int ndfc_calculate_ecc(struct mtd_info *mtd,
+			      const u_char *dat, u_char *ecc_code)
+{
+	struct nand_chip *this = mtd->priv;
+	struct of_ndfc_mtd *ndfc_mtd = this->priv;
+	struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+	uint32_t ecc;
+	uint8_t *p = (uint8_t *)&ecc;
+
+	wmb();
+	ecc = ndfc_raw_readl(ndfc, NDFC_ECC);
+	ecc_code[0] = p[1];
+	ecc_code[1] = p[2];
+	ecc_code[2] = p[3];
+
+	return 0;
+}
+
+
+/*
+ * Speedups for buffer read/write/verify
+ *
+ * NDFC allows 32bit read/write of data. So we can speed up the buffer
+ * functions. No further checking, as nand_base will always read/write
+ * page aligned.
+ */
+static void ndfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
+{
+	struct nand_chip *this = mtd->priv;
+	struct of_ndfc_mtd *ndfc_mtd = this->priv;
+	struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+	uint32_t *p = (uint32_t *) buf;
+
+	for(;len > 0; len -= 4)
+		*p++ = ndfc_raw_readl(ndfc, NDFC_DATA);
+}
+
+static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
+{
+	struct nand_chip *this = mtd->priv;
+	struct of_ndfc_mtd *ndfc_mtd = this->priv;
+	struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+	uint32_t *p = (uint32_t *) buf;
+
+	for(;len > 0; len -= 4)
+		ndfc_raw_writel(ndfc, NDFC_DATA, *p++);
+}
+
+static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
+{
+	struct nand_chip *this = mtd->priv;
+	struct of_ndfc_mtd *ndfc_mtd = this->priv;
+	struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+	uint32_t *p = (uint32_t *) buf;
+
+	for(;len > 0; len -= 4)
+		if (*p++ != ndfc_raw_readl(ndfc, NDFC_DATA))
+			return -EFAULT;
+	return 0;
+}
+
+
+#ifdef CONFIG_MTD_PARTITIONS
+#define OF_FLASH_PARTS(ndfc_mtd)	((ndfc_mtd)->parts)
+static int __devinit parse_partitions(struct of_ndfc_mtd *ndfc_mtd,
+				      struct device_node *dp)
+{
+	const char *partname;
+	static const char *part_probe_types[]
+		= { "cmdlinepart", "RedBoot", NULL };
+	struct device_node *pp;
+	int nr_parts, i;
+
+	/* First look for RedBoot table or partitions on the command
+	 * line, these take precedence over device tree information */
+	nr_parts = parse_mtd_partitions(&ndfc_mtd->mtd, part_probe_types,
+					&ndfc_mtd->parts, 0);
+	if (nr_parts > 0)
+		return nr_parts;
+
+	/* First count the subnodes */
+	nr_parts = 0;
+	for (pp = of_get_next_child(dp, NULL); pp;
+	     pp = of_get_next_child(dp, pp))
+		nr_parts++;
+
+	if (nr_parts == 0)
+		return 0;
+
+	ndfc_mtd->parts = kzalloc(nr_parts * sizeof(*ndfc_mtd->parts),
+					GFP_KERNEL);
+	if (!ndfc_mtd->parts)
+		return -ENOMEM;
+
+	for (pp = of_get_next_child(dp, NULL), i = 0; pp;
+	     pp = of_get_next_child(dp, pp), i++) {
+		const u32 *reg;
+		int len;
+
+		reg = of_get_property(pp, "reg", &len);
+		if (!reg || (len != 2*sizeof(u32))) {
+			of_node_put(pp);
+			printk(KERN_ERR "%s: Invalid 'reg'\n",
+				dp->full_name);
+			kfree(ndfc_mtd->parts);
+			ndfc_mtd->parts = NULL;
+			return -EINVAL;
+		}
+		ndfc_mtd->parts[i].offset = reg[0];
+		ndfc_mtd->parts[i].size = reg[1];
+
+		partname = of_get_property(pp, "label", &len);
+		if (!partname)
+			partname = of_get_property(pp, "name", &len);
+		ndfc_mtd->parts[i].name = (char *)partname;
+
+		if (of_get_property(pp, "read-only", &len))
+			ndfc_mtd->parts[i].mask_flags = MTD_WRITEABLE;
+	}
+
+	return nr_parts;
+}
+#else /* MTD_PARTITIONS */
+#define	OF_FLASH_PARTS(ndfc_mtd)		(0)
+static inline int parse_partitions(struct of_ndfc *ndfc, struct of_device *dev)
+{
+	return 0;
+}
+#endif /* MTD_PARTITIONS */
+
+
+static inline uint32_t ndfc_mtd_bank_mask(struct of_ndfc_mtd *ndfc_mtd)
+{
+	unsigned i;
+	uint32_t mask = 0;
+
+	for (i = 0; i < ndfc_mtd->chip_cnt; i++)
+		mask |= 1 << ndfc_mtd->banks[i];
+
+	return mask;
+}
+
+
+static inline void ndfc_del_mtd(struct of_ndfc *ndfc, struct of_ndfc_mtd *ndfc_mtd)
+{
+	uint32_t busy;
+
+	list_del(&ndfc_mtd->list);
+	busy = ndfc_mtd_bank_mask(ndfc_mtd);
+	ndfc->bank_mask &= ~busy;
+}
+
+
+static inline void ndfc_add_mtd(struct of_ndfc *ndfc, struct of_ndfc_mtd *ndfc_mtd)
+{
+	uint32_t busy;
+
+	busy = ndfc_mtd_bank_mask(ndfc_mtd);
+	ndfc->bank_mask |= busy;
+	list_add(&ndfc_mtd->list, &ndfc->list);
+}
+
+
+static int of_ndfc_remove(struct of_device *dev)
+{
+	struct of_ndfc_mtd *ndfc_mtd, *ndfc_mtd_next;
+	struct of_ndfc *ndfc;
+
+	ndfc = dev_get_drvdata(&dev->dev);
+	if (!ndfc)
+		return 0;
+
+	/* remove all mtd devices first*/
+	list_for_each_entry_safe(ndfc_mtd, ndfc_mtd_next,
+				&ndfc->list, list) {
+		if (OF_FLASH_PARTS(ndfc_mtd)) {
+			del_mtd_partitions(&ndfc_mtd->mtd);
+			kfree(OF_FLASH_PARTS(ndfc_mtd));
+		} else {
+			del_mtd_device(&ndfc_mtd->mtd);
+		}
+		nand_release(&ndfc_mtd->mtd);
+
+		ndfc_del_mtd(ndfc, ndfc_mtd);
+		kfree(ndfc_mtd);
+	}
+
+	dev_set_drvdata(&dev->dev, NULL);
+
+	if (ndfc->base)
+		iounmap(ndfc->base);
+
+	if (ndfc->res) {
+		release_resource(ndfc->res);
+		kfree(ndfc->res);
+	}
+
+	kfree(ndfc);
+	return 0;
+}
+
+
+static int __devinit ndfc_get_bank_map_prop(struct device_node *dp,
+					    unsigned char *map,
+					    uint32_t busy)
+{
+	const u32 *prop;
+	u32 val, len, mask;
+	int i;
+
+	prop = of_get_property(dp, "bank-map", &len);
+	if (!prop || (len < sizeof(u32)))
+		return -EFAULT;
+
+	for (i = 0; i < len / sizeof(u32); i++) {
+		val = prop[i];
+		if (val > NDFC_MAX_BANKS) {
+			printk(KERN_ERR "%s: Invalid bank (%i)\n",
+				dp->full_name, val);
+			return -EINVAL;
+		}
+
+		mask = 1 << val;
+		if (busy & mask) {
+			printk(KERN_ERR "%s: Busy bank (%i)\n",
+				dp->full_name, val);
+			return -EBUSY;
+		}
+
+		busy |= mask;
+		map[i] = (unsigned char)val;
+	}
+	return i;
+}
+
+
+static __devinit void ndfc_mtd_chip_init(struct of_ndfc_mtd *ndfc_mtd,
+					 struct device_node *dp)
+{
+	struct of_ndfc *ndfc = ndfc_mtd->ndfc;
+	struct nand_chip *chip = &ndfc_mtd->chip;
+	const u32 *prop;
+
+	chip->IO_ADDR_R = ndfc->base + NDFC_DATA;
+	chip->IO_ADDR_W = ndfc->base + NDFC_DATA;
+	chip->cmd_ctrl = ndfc_hwcontrol;
+	chip->dev_ready = ndfc_ready;
+	chip->select_chip = ndfc_select_chip;
+	chip->controller = &ndfc->control;
+	chip->read_buf = ndfc_read_buf;
+	chip->write_buf = ndfc_write_buf;
+	chip->verify_buf = ndfc_verify_buf;
+	chip->ecc.correct = nand_correct_data;
+	chip->ecc.hwctl = ndfc_enable_hwecc;
+	chip->ecc.calculate = ndfc_calculate_ecc;
+	chip->ecc.mode = NAND_ECC_HW;
+	chip->ecc.size = 256;
+	chip->ecc.bytes = 3;
+
+	/* look for chip options */
+	prop = of_get_property(dp, "chip-options", NULL);
+	if (prop)
+		ndfc_mtd->chip.options = *prop;
+
+	/* look for chip delay */
+	prop = of_get_property(dp, "chip-delay", NULL);
+	if (prop)
+		chip->chip_delay = *prop;
+	else
+		chip->chip_delay = 50;
+	chip->priv = ndfc_mtd;
+}
+
+
+static int __devinit ndfc_init_mtd(struct of_ndfc *ndfc, struct device_node *dp)
+{
+	const u32 *prop;
+	uint32_t bcr;
+	struct of_ndfc_mtd *ndfc_mtd;
+	int i, err;
+
+	if (!ndfc || !dp)
+		return -EINVAL;
+
+	ndfc_mtd = kzalloc(sizeof(struct of_ndfc_mtd), GFP_KERNEL);
+	if (!ndfc_mtd)
+		return -ENOMEM;
+
+	ndfc_mtd->ndfc = ndfc;
+
+	/* look for a bank-map */
+	err = ndfc_get_bank_map_prop(dp, ndfc_mtd->banks, ndfc->bank_mask);
+	if (err < 0)
+		goto err_out;
+
+	if (err == 0) {
+		err = -ENODEV;
+		goto err_out;
+	}
+	ndfc_mtd->chip_cnt = err;
+
+	/* look for bank settings */
+	prop = of_get_property(dp, "bank-settings", NULL);
+	if (prop) {
+		bcr = *prop | NDFC_BxCFG_EN;
+	} else {
+		bcr = NDFC_BxCFG_RR(2) | NDFC_BxCFG_RWH(2) |
+			NDFC_BxCFG_RWP(2) | NDFC_BxCFG_CRW(2);
+	}
+
+	/* look for bank width */
+	prop = of_get_property(dp, "bank-width", NULL);
+	if (prop && (*prop == 2))
+		bcr |= NDFC_BxCFG_SZ_16BIT;
+
+	/* setup banks for this mtd device */
+	for (i = 0; i < ndfc_mtd->chip_cnt; i++) {
+		ndfc_raw_writel(ndfc,
+				NDFC_BCFG0 + (ndfc_mtd->banks[i] << 2), bcr);
+	}
+
+	ndfc_mtd_chip_init(ndfc_mtd, dp);
+
+	if (bcr & NDFC_BxCFG_SZ_16BIT)
+		ndfc_mtd->chip.options |= NAND_BUSWIDTH_16;
+
+	ndfc_mtd->mtd.priv = &ndfc_mtd->chip;
+	ndfc_mtd->mtd.owner = THIS_MODULE;
+
+	/* scan for known chips */
+	err = nand_scan(&ndfc_mtd->mtd, ndfc_mtd->chip_cnt);
+	if (err)
+		goto err_out;
+
+	/* get partitions */
+	err = parse_partitions(ndfc_mtd, dp);
+	if (err < 0)
+		goto err_out;
+
+	/* attach mtd device to ndfc */
+	ndfc_add_mtd(ndfc, ndfc_mtd);
+
+	if (err > 0) {
+		add_mtd_partitions(&ndfc_mtd->mtd,
+					OF_FLASH_PARTS(ndfc_mtd), err);
+	} else {
+		add_mtd_device(&ndfc_mtd->mtd);
+	}
+
+	return 0;
+err_out:
+	kfree(ndfc_mtd);
+	return err;
+}
+
+
+static int __devinit ndfc_map_banks(struct of_ndfc *ndfc,
+				    struct of_device *dev)
+{
+	int i, err;
+	struct device_node *dp = dev->node, *pp;
+
+	if (!ndfc || !dev)
+		return -EINVAL;
+
+	/* Disable all banks */
+	for (i = 0; i < NDFC_MAX_BANKS; i++)
+		ndfc_raw_writel(ndfc, NDFC_BCFG0 + (i << 2), 0);
+
+	/* Scan device tree for nand devices attached and init them */
+	i = 0;
+	for (pp = of_get_next_child(dp, NULL); pp;
+	     pp = of_get_next_child(dp, pp)) {
+		err = ndfc_init_mtd(ndfc, pp);
+		if (err) {
+			printk(KERN_ERR "%s: Failed to map\n",
+				pp->full_name);
+			continue;
+		}
+		i++;
+	}
+	return i;
+}
+
+
+static int __devinit of_ndfc_probe(struct of_device *dev,
+				   const struct of_device_id *match)
+{
+	struct device_node *dp = dev->node;
+	struct resource res;
+	struct of_ndfc *ndfc;
+	resource_size_t rlen;
+	int err;
+
+	err = -ENXIO;
+	if (of_address_to_resource(dp, 0, &res)) {
+		dev_err(&dev->dev, "Can't get IO address from device tree\n");
+		goto err_out;
+	}
+
+	dev_dbg(&dev->dev, "of_nand device: %.8llx-%.8llx\n",
+		(unsigned long long)res.start, (unsigned long long)res.end);
+
+	ndfc = kzalloc(sizeof(struct of_ndfc), GFP_KERNEL);
+	if (!ndfc) {
+		err = -ENOMEM;
+		goto err_out;
+	}
+
+	rlen = res.end - res.start + 1;
+	ndfc->res = request_mem_region(res.start, rlen, dev->dev.bus_id);
+	if (!ndfc->res) {
+		err = -EBUSY;
+		goto err_free_out;
+	}
+
+	ndfc->base = ioremap(res.start, rlen);
+	if (!ndfc->base) {
+		err = -ENXIO;
+		goto err_rel_out;
+	}
+
+	spin_lock_init(&ndfc->control.lock);
+	init_waitqueue_head(&ndfc->control.wq);
+	INIT_LIST_HEAD(&ndfc->list);
+
+	err = ndfc_map_banks(ndfc, dev);
+	if (err <= 0) {
+		printk(KERN_ERR "NDFC NAND: (%s) no banks set up\n",
+			dp->full_name);
+		err = -ENODEV;
+		goto err_unmap_out;
+	}
+
+	dev_set_drvdata(&dev->dev, ndfc);
+	printk(KERN_INFO "NDFC NAND Driver initialized. "
+			"Chip-Rev: 0x%08x\n", ndfc_raw_readl(ndfc, NDFC_REVID));
+
+	return 0;
+
+err_unmap_out:
+	iounmap(ndfc->base);
+err_rel_out:
+	release_resource(ndfc->res);
+	kfree(ndfc->res);
+err_free_out:
+	kfree(ndfc);
+err_out:
+	return err;
+}
+
+static struct of_device_id of_ndfc_match[] = {
+	{
+		.compatible	= "ibm,ndfc",
+	},
+	{ },
+};
+MODULE_DEVICE_TABLE(of, of_ndfc_match);
+
+static struct of_platform_driver of_ndfc_driver = {
+	.name		= "of-ndfc",
+	.match_table	= of_ndfc_match,
+	.probe		= of_ndfc_probe,
+	.remove		= of_ndfc_remove,
+};
+
+static int __init of_ndfc_init(void)
+{
+	return of_register_platform_driver(&of_ndfc_driver);
+}
+
+static void __exit of_ndfc_exit(void)
+{
+	of_unregister_platform_driver(&of_ndfc_driver);
+}
+
+module_init(of_ndfc_init);
+module_exit(of_ndfc_exit);
+
+MODULE_LICENSE("GPL");
+
+
+MODULE_DESCRIPTION("Platform driver for NDFC");
diff -pruN linux-2.6.orig/include/linux/mtd/ndfc.h linux-2.6/include/linux/mtd/ndfc.h
--- linux-2.6.orig/include/linux/mtd/ndfc.h	2007-10-29 16:03:16.000000000 +0300
+++ linux-2.6/include/linux/mtd/ndfc.h	2007-10-29 18:59:11.000000000 +0300
@@ -52,6 +52,10 @@
 #define NDFC_BxCFG_SZ_MASK	0x08000000 /* Bank Size */
 #define NDFC_BxCFG_SZ_8BIT	0x00000000 /* 8bit */
 #define NDFC_BxCFG_SZ_16BIT	0x08000000 /* 16bit */
+#define NDFC_BxCFG_RR(x)	((x) & 0x3 << 0)
+#define NDFC_BxCFG_RWH(x)	((x) & 0x3 << 4)
+#define NDFC_BxCFG_RWP(x)	((x) & 0x3 << 8)
+#define NDFC_BxCFG_CRW(x)	((x) & 0x3 << 12)
 
 #define NDFC_MAX_BANKS		4
 

[PATCH 2/3] PowerPC: 44x NanD Flash Controller (NDFC) bindings

[Valentine Barshak]

PowerPC 44x NanD Flash Controller (NDFC) bindings.

Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
 Documentation/powerpc/booting-without-of.txt |   64 +++++++++++++++++++++++++++
 1 files changed, 64 insertions(+)

--- linux-2.6.orig/Documentation/powerpc/booting-without-of.txt	2007-10-29 16:02:07.000000000 +0300
+++ linux-2.6/Documentation/powerpc/booting-without-of.txt	2007-10-29 21:34:14.000000000 +0300
@@ -52,6 +52,7 @@ Table of Contents
       i) Freescale QUICC Engine module (QE)
       j) CFI or JEDEC memory-mapped NOR flash
       k) Global Utilities Block
+      l) 44x NanD Flash Controller (NDFC)
 
   VII - Specifying interrupt information for devices
     1) interrupts property
@@ -2242,6 +2243,69 @@ platforms are moved over to use the flat
 			   available.
 			   For Axon: 0x0000012a
 
+  l) 44x NanD Flash Controller (NDFC)
+
+  Required properties:
+  - compatible : should be "ibm,ndfc".
+  - reg : should contain address and length of the NDFC registers.
+  
+  ndfc node should contain at least one ndfc-mtd sub-node describing
+  chip properties and bank settings for the chip(s) attached to particular
+  ndfc bank(s).
+
+  Required ndfc-mtd properties:
+  - bank-map : at least one value (less than number of NDFC banks available)
+    identifying bank number the chip is attached to. If we have several
+    identical chips and want to spread a single mtd device across all of them,
+    we need to specify here the bank numbers the chips are attached to.
+    E.g. "bank-map = <0 3>;" means a single mtd device will be created 
+    for 2 identical NAND chips attached to banks 0 and 3 of the NDFC.
+  Optional ndfc-mtd properties:
+  - chip-options : NAND chip options.
+  - chip-delay : NAND chip delay. Default is 50us.
+  - bank-settings : NDFC bank settings for the chip(s). This value is
+    written to the NDFC Bank Configuration Register.
+    If not specified, the default timings (RR=RWH=RWP=CRW=2) and 
+    bank width from the "bank-width" property will be used for the chip.
+  - bank-width : NAND chip bus width. Should be 1 for 8-bit NAND or 
+    2 for 16-bit NAND. By default an 8-bit width is set.
+  - #address-cells, #size-cells : Must be present if the flash has
+    sub-nodes representing partitions (see below).  In this case
+    both #address-cells and #size-cells must be equal to 1.
+  
+  ndfc_mtd can have partition sub-nodes, which are described the same way
+  as for the CFI or JEDEC memory-mapped NOR flash.
+
+   Example (Sequoia 440EPx):
+   NDFC is relocatable within EBC and should have EBC as a parent node.
+   Here we have NDFC on EBC CS3 bank and one NAND chip attached to bank 3
+   of the NanD Flash Controller:
+
+		ndfc@0,0 {
+			compatible = "ibm,ndfc-440epx", "ibm,ndfc";
+			reg = <3 000000 2000>;
+			ndfc-mtd0 {
+				bank-settings = <80002222>;
+				bank-map = <3>;
+				chip-delay = <32>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				partition@0 {
+					label = "u-boot-nand";
+					reg = <0 0080000>;
+				};
+				partition@80000 {
+					label = "kernel-nand";
+					reg = <0080000 0180000>;
+				};
+				partition@200000 {
+					label = "filesystem";
+					reg = <0200000 1e00000>;
+				};
+			};
+		};
+
+
    More devices will be defined as this spec matures.
 
 VII - Specifying interrupt information for devices

[PATCH 3/3] PowerPC: NDFC entry for 440EPx Sequoia DTS

[Valentine Barshak]

NDFC DTS entry for PowerPC 440EPx Sequoia board.

Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
 arch/powerpc/boot/dts/sequoia.dts |   23 +++++++++++++++++++++++
 1 files changed, 23 insertions(+)

diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts linux-2.6/arch/powerpc/boot/dts/sequoia.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts	2007-10-29 16:02:11.000000000 +0300
+++ linux-2.6/arch/powerpc/boot/dts/sequoia.dts	2007-10-29 18:59:11.000000000 +0300
@@ -141,6 +141,29 @@
 				interrupts = <5 1>;
 				interrupt-parent = <&UIC1>;
 
+				ndfc@0,0 {
+					compatible = "ibm,ndfc-440epx", "ibm,ndfc";
+					reg = <3 000000 2000>;
+					ndfc-mtd0 {
+						bank-settings = <80002222>;
+						bank-map = <3>;
+						chip-delay = <32>;
+						#address-cells = <1>;
+						#size-cells = <1>;
+						partition@0 {
+							label = "u-boot-nand";
+							reg = <0 0080000>;
+						};
+						partition@80000 {
+							label = "kernel-nand";
+							reg = <0080000 0180000>;
+						};
+						partition@200000 {
+							label = "filesystem";
+							reg = <0200000 1e00000>;
+						};
+					};
+				};
 				nor_flash@0,0 {
 					compatible = "amd,s29gl256n", "cfi-flash";
 					bank-width = <2>;

Re: [PATCH 0/3] Add device-tree aware NDFC driver

[Thomas Gleixner]

On Mon, 29 Oct 2007, Valentine Barshak wrote:

> This adds a device-tree aware PowerPC 44x NanD Flash Controller driver
> The code is based on the original NDFC driver by Thomas Gleixner, but
> since it's been changed much and has initialization/clean-up completely
> reworked it's been put into a separate ndfc_of.c file. This version
> supports both separate mtd devices on each chip attached to NDFC banks and
> single mtd device spread across identical chips (not using mtdconcat) as well.
> The choice is selected with device tree settings. This has been tested
> on PowerPC 440EPx Sequoia board.
> Any comments are greatly appreciated.

Did I express myself not clear enough in my first reply or is this
just a repeated epiphany in my inbox ? 

You got plenty of comments to your patches, but you decided to ignore
them silently.

Darn, fix it the right way once and forever and please don't try to
tell me another heartrending "why I did it my way" story.

This all can be done with a nice series of incremental patches
including a fixup to the existing users.

We have enough dump and run shit in the kernel already.

No thanks,

   tglx

Re: [PATCH 0/3] Add device-tree aware NDFC driver

[Valentine Barshak]

Thomas Gleixner wrote:
> On Mon, 29 Oct 2007, Valentine Barshak wrote:
> 
>> This adds a device-tree aware PowerPC 44x NanD Flash Controller driver
>> The code is based on the original NDFC driver by Thomas Gleixner, but
>> since it's been changed much and has initialization/clean-up completely
>> reworked it's been put into a separate ndfc_of.c file. This version
>> supports both separate mtd devices on each chip attached to NDFC banks and
>> single mtd device spread across identical chips (not using mtdconcat) as well.
>> The choice is selected with device tree settings. This has been tested
>> on PowerPC 440EPx Sequoia board.
>> Any comments are greatly appreciated.
> 
> Did I express myself not clear enough in my first reply or is this
> just a repeated epiphany in my inbox ? 
> 
> You got plenty of comments to your patches, but you decided to ignore
> them silently.
> 
> Darn, fix it the right way once and forever and please don't try to
> tell me another heartrending "why I did it my way" story.
> 
> This all can be done with a nice series of incremental patches
> including a fixup to the existing users.
> 
> We have enough dump and run shit in the kernel already.
> 
> No thanks,
> 
>    tglx

You know, you're really too tense Thomas. I'm not sure of the reason why 
you're being a complete nerve, but I'm feeling sorry for you.
I'm not saying my approach is the best, but I was hoping for a discussion.
I've reworked the patches according to the comments to the previous 
version and used my arguments to explain why I don't see much reason to 
mess with the code we currently have and added a separate _of version.
I'm sure you'd find some time to do it yourself "the right way once and 
forever" with a "nice series of incremental patches" to fix what we 
currently have (call it a "dump" or anything you like) and even maybe 
add new device tree support.
I'm sorry if for some reason I've made you feel bad.
This is the last time I disturb you with my e-mail, so please, forget it.
Thank you very much for your comments anyway.
It's been nice talking to you,
Valentine.

Re: [PATCH 0/3] Add device-tree aware NDFC driver

[Jörn Engel]

On Tue, 30 October 2007 17:13:08 +0300, Valentine Barshak wrote:
> 
> I'm not saying my approach is the best, but I was hoping for a discussion.

That is good.  So please take a moment to listen.

> I've reworked the patches according to the comments to the previous 
> version and used my arguments to explain why I don't see much reason to 
> mess with the code we currently have and added a separate _of version.

Ok.

> This is the last time I disturb you with my e-mail, so please, forget it.

Thomas words were harsh.  Nothing unusual so far.  Some people deserve
harsh words, some don't and some simply are doing a good job to invite
them.  You mails so far were inviting harsh words.

So how did you invite harsh words and what can you change to prevent
this in the future?

1. Develop a thicker skin.  No matter how well you do, there will always
be the occasional harsh words, deserved or not.  It is ok to get angry
and call the person names - but do that at home and leave it out of your
responses.  Ignore the flamebait, at least in public.

2. Follow local customs.  In particular you should follow the style of
discussion commonly used in mailing lists:

	>>> I'm doing this.
	>> Crap! Never do that!
	> Why not?  Can you explain?
	Because...

	>>> Then I do that.
	>> Wouldn't ABCD be better?
	> ABCD wouldn't work for me because of XYZ.
	Fair enough.

Respond to individual comments _directly_following_the_comment_ do not
collect comments from 10 mails, then respond to them all in a long
paragraph.  Noone will read that.  I didn't read it either.

3. Be concise.  When quoting someone, remove everything but the relevant
bits.  Respond only with relevant information.  People regularly read
10+ mailing lists.  Their attention span is short.  If you manage to
annoy them with irrelevant information in the first 10 lines, they will
skip any amount of wisdom below.

4. Be polite.  Even if the responses you get are not.  Flamewars get you
nowhere.

5. Have sound technical arguments.  "mtd concat adds a slight overhead"
is not for two reasons.  First, it is lacking numbers.  People's guesses
about perceived overhead or usually wrong, so knowledgeable readers will
immediately question such arguments.  Secondly, you didn't explain _why_
mtdconcat adds overhead.  In particular, why didn't you reduce the
mtdconcat overhead instead of essentially copying its functionality?

6. Be structured.  Empty lines are cheap.  Use them.  Add structure to
your mails.  Above you can see several paragraphs.  You can quickly go
back to a previous one.  You can skip one after reading just the first
sentence.  After several attempts I still haven't read your 46-line
monologue.  I don't even know how far I made it because it is so damn
hard to find the spot again.


If you are willing to change the style of your mails, maybe people will
actually read them and respond to you in ways you expected.  Otherwise
it may indeed be a wise choice not to come back.  Some people simply
just don't get along.  Sometimes a proxy is needed to translate between
people.  But my hope is that you are willing and able to work with us
directly.

Jörn

-- 
There is no worse hell than that provided by the regrets
for wasted opportunities.
-- Andre-Louis Moreau in Scarabouche

Re: [PATCH 0/3] Add device-tree aware NDFC driver

[Thomas Gleixner]

Valentine,

On Tue, 30 Oct 2007, Valentine Barshak wrote:
> Thomas Gleixner wrote:
> > On Mon, 29 Oct 2007, Valentine Barshak wrote:
> > 
> > > This adds a device-tree aware PowerPC 44x NanD Flash Controller driver
> > > The code is based on the original NDFC driver by Thomas Gleixner, but
> > > since it's been changed much and has initialization/clean-up completely
> > > reworked it's been put into a separate ndfc_of.c file. This version
> > > supports both separate mtd devices on each chip attached to NDFC banks and
> > > single mtd device spread across identical chips (not using mtdconcat) as
> > > well.
> > > The choice is selected with device tree settings. This has been tested
> > > on PowerPC 440EPx Sequoia board.
> > > Any comments are greatly appreciated.
> > 
> > Did I express myself not clear enough in my first reply or is this
> > just a repeated epiphany in my inbox ? 
> > You got plenty of comments to your patches, but you decided to ignore
> > them silently.
> > 
> > Darn, fix it the right way once and forever and please don't try to
> > tell me another heartrending "why I did it my way" story.
> > 
> > This all can be done with a nice series of incremental patches
> > including a fixup to the existing users.
> > 
> > We have enough dump and run shit in the kernel already.
> > 
> > No thanks,
> > 
> >    tglx
> 
> You know, you're really too tense Thomas. I'm not sure of the reason why
> you're being a complete nerve, but I'm feeling sorry for you.

You have a perception problem. I'm not tense, I'm grumpy.

Rest assured, that my nerves are completely fine despite of the fact
that you try to rack them.

> I'm not saying my approach is the best, but I was hoping for a discussion.
> I've reworked the patches according to the comments to the previous version
> and used my arguments to explain why I don't see much reason to mess with the
> code we currently have and added a separate _of version.

This is the exact point. You were asked to fix up the existing driver
instead of replacing it and to do it with a series of incremental
patches. You copied the old code anyway and modified it, so we want to
have this documented in the history. This is not my obsession, it's
common kernel coding practise. The fact that you do not see much
reason to do it does not change this at all.

> I'm sure you'd find some time to do it yourself "the right way once and
> forever" with a "nice series of incremental patches" to fix what we currently
> have (call it a "dump" or anything you like) and even maybe add new device
> tree support.

It might be time for you to try to understand how OSS development
works.

> I'm sorry if for some reason I've made you feel bad.

What do you expect, after you abused my Signed-off-by in a way which
might have tricked David into pulling your code as is? This was
pointed out to you and you did not even bother to apologize.

> This is the last time I disturb you with my e-mail, so please, forget it.

Interesting. I thought you wanted to get the patch in, so you probably
should ask yourself whether it is a good idea _not_ to talk to the
responsible maintainer.

If you gave up on that, it just makes it more obvious that you do not
want to work with the community and just wanted to dump your patch and
move along.

     tglx

Re: [PATCH 0/3] Add device-tree aware NDFC driver

[Valentine Barshak]

Thomas Gleixner wrote:
> Valentine,
>> You know, you're really too tense Thomas. I'm not sure of the reason why
>> you're being a complete nerve, but I'm feeling sorry for you.
> 
> You have a perception problem. I'm not tense, I'm grumpy.

:)

> 
> Rest assured, that my nerves are completely fine despite of the fact
> that you try to rack them.

That's good to hear :)

> 
>> I'm not saying my approach is the best, but I was hoping for a discussion.
>> I've reworked the patches according to the comments to the previous version
>> and used my arguments to explain why I don't see much reason to mess with the
>> code we currently have and added a separate _of version.
> 
> This is the exact point. You were asked to fix up the existing driver
> instead of replacing it and to do it with a series of incremental
> patches. You copied the old code anyway and modified it, so we want to
> have this documented in the history. This is not my obsession, it's
> common kernel coding practise. The fact that you do not see much
> reason to do it does not change this at all.

Replacing the original driver is not my obsession either.
I just don't see the "right" way to modify the original driver to 
support both platform devices and the new OF implementation. I see some 
initialization order problems with the original version, and I think 
that the easiest way to handle ndfc and chips attached to it would be to 
  do it in a single probe() function instead of having separate chip 
devices and a separate ndfc platform device on top of that.

So, my opinion is that modifying the original code involves ndfc users' 
modification. Considering the fact that ppc removal is scheduled for the 
next summer, I thought that we could leave the original version intact 
and build the new OF one.

I know the common kernel practice, but if we always followed it we'd 
never bring up arch/powerpc.
BTW, I've posted some of the ndfc questions to the MTD mailing list
(http://lists.infradead.org/pipermail/linux-mtd/2007-November/019769.html). 
If I had the answers I might get a more clear idea about the right way 
to do it. I'd appreciate if you could take a look.

> 
>> I'm sure you'd find some time to do it yourself "the right way once and
>> forever" with a "nice series of incremental patches" to fix what we currently
>> have (call it a "dump" or anything you like) and even maybe add new device
>> tree support.
> 
> It might be time for you to try to understand how OSS development
> works.

I do understand how it works.

> 
>> I'm sorry if for some reason I've made you feel bad.
> 
> What do you expect, after you abused my Signed-off-by in a way which
> might have tricked David into pulling your code as is? This was
> pointed out to you and you did not even bother to apologize.

I apologize.
If I wanted to abuse or trick somebody and get my code in as fast as 
possible no matter what, I wouldn't cc the maintainer, the other people 
interested and send it to both mtd and ppc mailing lists.
I don't see any possible way for a guy who hasn't worked with the MTD 
community much to trick someone and get his patches in.

> 
>> This is the last time I disturb you with my e-mail, so please, forget it.
> 
> Interesting. I thought you wanted to get the patch in, so you probably
> should ask yourself whether it is a good idea _not_ to talk to the
> responsible maintainer.

As I said above, I don't see the "right" way to do it. And actually I 
didn't expect you to share your thoughts and reasons on how to support 
both implementations and why this way is preferred. All I heard were 
cursing and direct orders to stop tying to explain my reasons and do it 
the "right" way. It looked like the responsible maintainer just wouldn't 
listen. Why talk then?

> 
> If you gave up on that, it just makes it more obvious that you do not
> want to work with the community and just wanted to dump your patch and
> move along.

I never give up ;) and I didn't say I was going to stop working with the 
community.

> 
>      tglx

Cheers,
Valentine.