[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Huang Shijie]

The patch is based on branch "imx-for-3.1" of tree :
      git://git.pengutronix.de/git/imx/linux-2.6.git

The general-purpose media interface(GPMI) controller is a flexible interface
to up to several NAND flashs.

The Bose Ray-Choudhury Hocquenghem(BCH) module is a hardware ECC accelerator.

With the help of BCH, the GPMI controller can choose to do the hardware ECC or
not.

This driver is a _pure_ MTD NAND controller driver now.

To Walfram & Artem:
    About how to disable the JFFS2 to use the OOB:
    I read the code, and I still have no idea about how to use the ecclayout
    to do the job. Could you give me some hint? thanks.

The driver depends on another GPMI-NAND device patch set, you can find them at :
	[1] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037033.html
	[2] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037031.html
	[3] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037032.html
	[4] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037034.html

The driver also depends on another DMA patch by Shawn:
	[0] http://lists.infradead.org/pipermail/linux-mtd/2011-June/036820.html

Test environment:
	Using imx23 and imx28 boards for test. 

	imx23 (burn the rootfs to NAND):
	console=ttyAMA0,115200 mtdparts=gpmi-nfc:20m(boot),-(user)  ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifs gpmi_debug_init

        imx28 :
	#console=ttyAMA0,115200 root=/dev/mmcblk0p3 rw rootwait gpmi_debug_init
	#console=ttyAMA0,115200 root=/dev/nfs ip=:::::eth0:dhcp nfsroot=10.192.242.11:/root/nfs_root/imx28 gpmi_debug_init

v7 --> v8:
	[0] rename the name from `GPMI-NFC` to `GPMI-NAND`
	[1] remove the `hal` layer, and change it to function library.
	[2] Do not use ~0 to initialize the DMA address.
	[3] fix the issue : several DMA channels share the same IRQ.
	[4] DMA timeout issue. I use the .config created by `make mxs_defconfig`
	    and the bug never occur. It seems some other module has impact to the
	    DMA.
	    Of course, you should enable the UBIFS,MTD_CHAR and GPMI for
	    the .config. You can also disable the SPIN-LOCK/MUTEX debug features.
	[5] add function to print out the GPMI registers.	    
	[6] others.	    

v6 --> v7:
	[0] remove the function wrapping the clock.
	[1] use the module_param() for debugging.
	[2] use the new interface of MTD partitions.
		replace add_mtd_partitions() with mtd_device_register().
	[3] use pr_info() to print log.
	[4] add `__devinit` for some functions, etc.
	[5] add `gpmi_nfc` to control the GPMI-NFC driver's initialization.
	[6] others.

v5 --> v6:
	[0] split out the IMX23/IMX28 arch code to separate patches.
	[1] fix bug : missing empty item in the end of platform_id array.
	[2] inconsistent identation.
	[3] others

v4 --> v5:
	[0] rename the files.
	[1] fix PM bug
	[2] remove the rom_helper code, and move the necessary initialization code
		to the main file.
	[3] change the macros from CPU_IS_* to GPMI_IS_*
	[4] remove the default partition layout init code. revert back the 
		partition parsing command line code.
	[5] others

v3 --> v4:
	[0] use the nand_ids{} as the nand database, drop my own database.
	[1] remove the patch for DMA enginer, Shawn will submit his own version.
	[2] use the platform_id to distinguish different Archs.
	[3] fix the strange coding style.
	[4] others.

v2 --> v3:
	[0] merge the imx23 and imx28 into one file(including the header file).
	[1] remove the unuse registers in the headers.
	[2] fix DMA bugs
	[3] add bus width field to nand_attr{}
	[4] others

v1 --> v2:
	[0] merge the common files into the gpmi-nfc-main.c
	[1] change the code to get the clock.
	[2] remove the timing in the nand_device_info{}
	[3] fix DMA errors
	[4] add the nand_device_info.[ch] to generic code
	[5] use the chip->onfi_version for the ONFI nand
	[6] useless init
	[7] others

Huang Shijie (3):
  MTD : add the common code for GPMI-NAND controller driver
  MTD : add helper functions library and header files for GPMI NAND
    driver
  MTD : add GPMI-NAND driver in the config and Makefile

 drivers/mtd/nand/Kconfig               |   11 +
 drivers/mtd/nand/Makefile              |    1 +
 drivers/mtd/nand/gpmi-nand/Makefile    |    3 +
 drivers/mtd/nand/gpmi-nand/bch-regs.h  |   88 ++
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |  978 ++++++++++++++++
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 1987 ++++++++++++++++++++++++++++++++
 drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  390 +++++++
 drivers/mtd/nand/gpmi-nand/gpmi-regs.h |  174 +++
 8 files changed, 3632 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mtd/nand/gpmi-nand/Makefile
 create mode 100644 drivers/mtd/nand/gpmi-nand/bch-regs.h
 create mode 100644 drivers/mtd/nand/gpmi-nand/gpmi-lib.c
 create mode 100644 drivers/mtd/nand/gpmi-nand/gpmi-nand.c
 create mode 100644 drivers/mtd/nand/gpmi-nand/gpmi-nand.h
 create mode 100644 drivers/mtd/nand/gpmi-nand/gpmi-regs.h

[PATCH v8 1/3] MTD : add the common code for GPMI-NAND controller driver

[Huang Shijie]

These files contain the common code for the GPMI-NAND driver.

Signed-off-by: Huang Shijie <b32955@freescale.com>
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 1987 ++++++++++++++++++++++++++++++++
 drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  390 +++++++
 2 files changed, 2377 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mtd/nand/gpmi-nand/gpmi-nand.c
 create mode 100644 drivers/mtd/nand/gpmi-nand/gpmi-nand.h

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
new file mode 100644
index 0000000..1c2cbc5
--- /dev/null
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -0,0 +1,1987 @@
+/*
+ * Freescale GPMI NAND Flash Driver
+ *
+ * Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
+ * Copyright (C) 2008 Embedded Alley Solutions, Inc.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+#include "gpmi-nand.h"
+
+/* add our owner bbt descriptor */
+static uint8_t scan_ff_pattern[] = { 0xff };
+static struct nand_bbt_descr gpmi_bbt_descr = {
+	.options	= 0,
+	.offs		= 0,
+	.len		= 1,
+	.pattern	= scan_ff_pattern
+};
+
+/* debug control */
+int gpmi_debug;
+module_param(gpmi_debug, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(gpmi_debug, "print out the debug infomation.");
+
+/* enable the gpmi-nand. */
+static bool enable_gpmi_nand;
+
+static ssize_t show_ignorebad(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct gpmi_nand_data *this = dev_get_drvdata(dev);
+	struct mil *mil = &this->mil;
+
+	return sprintf(buf, "%d\n", mil->ignore_bad_block_marks);
+}
+
+static ssize_t
+store_ignorebad(struct device *dev, struct device_attribute *attr,
+			const char *buf, size_t size)
+{
+	struct gpmi_nand_data *this = dev_get_drvdata(dev);
+	struct mil *mil = &this->mil;
+	const char *p = buf;
+	unsigned long v;
+
+	if (strict_strtoul(p, 0, &v) < 0)
+		return -EINVAL;
+
+	if (v > 0)
+		v = 1;
+
+	if (v != mil->ignore_bad_block_marks) {
+		if (v) {
+			/*
+			 * This will cause the NAND Flash MTD code to believe
+			 * that it never created a BBT and force it to call our
+			 * block_bad function.
+			 *
+			 * See mil_block_bad for more details.
+			 */
+			mil->saved_bbt = mil->nand.bbt;
+			mil->nand.bbt  = NULL;
+		} else {
+			/*
+			 * Restore the NAND Flash MTD's pointer
+			 * to its in-memory BBT.
+			 */
+			mil->nand.bbt = mil->saved_bbt;
+		}
+		mil->ignore_bad_block_marks = v;
+	}
+	return size;
+}
+
+static DEVICE_ATTR(ignorebad, 0644, show_ignorebad, store_ignorebad);
+static struct device_attribute *device_attributes[] = {
+	&dev_attr_ignorebad,
+};
+
+static irqreturn_t bch_irq(int irq, void *cookie)
+{
+	struct gpmi_nand_data *this = cookie;
+
+	gpmi_clear_bch(this);
+	complete(&this->bch_done);
+	return IRQ_HANDLED;
+}
+
+/* calculate the ECC strength by hand */
+static inline int get_ecc_strength(struct gpmi_nand_data *this)
+{
+	struct mtd_info	*mtd = &this->mil.mtd;
+	int ecc_strength = 0;
+
+	switch (mtd->writesize) {
+	case 2048:
+		ecc_strength = 8;
+		break;
+	case 4096:
+		switch (mtd->oobsize) {
+		case 128:
+			ecc_strength = 8;
+			break;
+		case 224:
+		case 218:
+			ecc_strength = 16;
+			break;
+		}
+		break;
+	case 8192:
+		ecc_strength = 24;
+		break;
+	}
+
+	return ecc_strength;
+}
+
+bool is_ddr_nand(struct gpmi_nand_data *this)
+{
+	struct nand_chip *chip = &this->mil.nand;
+
+	/* ONFI nand */
+	if (chip->onfi_version != 0)
+		return true;
+
+	/* TOGGLE nand */
+
+	return false;
+}
+
+static inline int get_ecc_chunk_size(struct gpmi_nand_data *this)
+{
+	/* the ONFI/TOGGLE nands use 1k ecc chunk size */
+	if (is_ddr_nand(this))
+		return 1024;
+
+	/* for historical reason */
+	return 512;
+}
+
+int common_nfc_set_geometry(struct gpmi_nand_data *this)
+{
+	struct bch_geometry *geo = &this->bch_geometry;
+	struct mtd_info *mtd = &this->mil.mtd;
+	unsigned int metadata_size;
+	unsigned int status_size;
+	unsigned int chunk_data_size_in_bits;
+	unsigned int chunk_ecc_size_in_bits;
+	unsigned int chunk_total_size_in_bits;
+	unsigned int block_mark_chunk_number;
+	unsigned int block_mark_chunk_bit_offset;
+	unsigned int block_mark_bit_offset;
+
+	/* We only support BCH now. */
+	geo->ecc_algorithm = "BCH";
+
+	/*
+	 * We always choose a metadata size of 10. Don't try to make sense of
+	 * it -- this is really only for historical compatibility.
+	 */
+	geo->metadata_size_in_bytes = 10;
+
+	/* ECC chunks */
+	geo->ecc_chunk_size_in_bytes = get_ecc_chunk_size(this);
+
+	/*
+	 * Compute the total number of ECC chunks in a page. This includes the
+	 * slightly larger chunk at the beginning of the page, which contains
+	 * both data and metadata.
+	 */
+	geo->ecc_chunk_count = mtd->writesize / geo->ecc_chunk_size_in_bytes;
+
+	/*
+	 * We use the same ECC strength for all chunks, including the first one.
+	 */
+	geo->ecc_strength = get_ecc_strength(this);
+	if (!geo->ecc_strength) {
+		pr_info("Page size:%d, OOB:%d\n", mtd->writesize, mtd->oobsize);
+		return -EINVAL;
+	}
+
+	/* Compute the page size, include page and oob. */
+	geo->page_size_in_bytes = mtd->writesize + mtd->oobsize;
+
+	/*
+	 * ONFI/TOGGLE nand needs GF14, so re-calculate DMA page size.
+	 * The ONFI nand must do the recalculation,
+	 * else it will fail in DMA in some platform(such as imx50).
+	 */
+	if (is_ddr_nand(this))
+		geo->page_size_in_bytes = mtd->writesize +
+				geo->metadata_size_in_bytes +
+			(geo->ecc_strength * 14 * 8 / geo->ecc_chunk_count);
+
+	geo->payload_size_in_bytes = mtd->writesize;
+	/*
+	 * In principle, computing the auxiliary buffer geometry is NFC
+	 * version-specific. However, at this writing, all versions share the
+	 * same model, so this code can also be shared.
+	 *
+	 * The auxiliary buffer contains the metadata and the ECC status. The
+	 * metadata is padded to the nearest 32-bit boundary. The ECC status
+	 * contains one byte for every ECC chunk, and is also padded to the
+	 * nearest 32-bit boundary.
+	 */
+	metadata_size = ALIGN(geo->metadata_size_in_bytes, 4);
+	status_size   = ALIGN(geo->ecc_chunk_count, 4);
+
+	geo->auxiliary_size_in_bytes = metadata_size + status_size;
+	geo->auxiliary_status_offset = metadata_size;
+
+	/* Check if we're going to do block mark swapping. */
+	if (!this->swap_block_mark)
+		return 0;
+
+	/*
+	 * If control arrives here, we're doing block mark swapping, so we need
+	 * to compute the byte and bit offsets of the physical block mark within
+	 * the ECC-based view of the page data. In principle, this isn't a
+	 * difficult computation -- but it's very important and it's easy to get
+	 * it wrong, so we do it carefully.
+	 *
+	 * Note that this calculation is simpler because we use the same ECC
+	 * strength for all chunks, including the zero'th one, which contains
+	 * the metadata. The calculation would be slightly more complicated
+	 * otherwise.
+	 *
+	 * We start by computing the physical bit offset of the block mark. We
+	 * then subtract the number of metadata and ECC bits appearing before
+	 * the mark to arrive at its bit offset within the data alone.
+	 */
+
+	/* Compute some important facts about chunk geometry. */
+	chunk_data_size_in_bits = geo->ecc_chunk_size_in_bytes * 8;
+
+	/* ONFI/TOGGLE nand needs GF14 */
+	if (is_ddr_nand(this))
+		chunk_ecc_size_in_bits  = geo->ecc_strength * 14;
+	else
+		chunk_ecc_size_in_bits  = geo->ecc_strength * 13;
+
+	chunk_total_size_in_bits =
+			chunk_data_size_in_bits + chunk_ecc_size_in_bits;
+
+	/* Compute the bit offset of the block mark within the physical page. */
+	block_mark_bit_offset = mtd->writesize * 8;
+
+	/* Subtract the metadata bits. */
+	block_mark_bit_offset -= geo->metadata_size_in_bytes * 8;
+
+	/*
+	 * Compute the chunk number (starting at zero) in which the block mark
+	 * appears.
+	 */
+	block_mark_chunk_number =
+			block_mark_bit_offset / chunk_total_size_in_bits;
+
+	/*
+	 * Compute the bit offset of the block mark within its chunk, and
+	 * validate it.
+	 */
+	block_mark_chunk_bit_offset =
+		block_mark_bit_offset -
+			(block_mark_chunk_number * chunk_total_size_in_bits);
+
+	if (block_mark_chunk_bit_offset > chunk_data_size_in_bits) {
+		/*
+		 * If control arrives here, the block mark actually appears in
+		 * the ECC bits of this chunk. This wont' work.
+		 */
+		pr_info("Unsupported page geometry : %u:%u\n",
+				mtd->writesize, mtd->oobsize);
+		return -EINVAL;
+	}
+
+	/*
+	 * Now that we know the chunk number in which the block mark appears,
+	 * we can subtract all the ECC bits that appear before it.
+	 */
+	block_mark_bit_offset -=
+			block_mark_chunk_number * chunk_ecc_size_in_bits;
+
+	/*
+	 * We now know the absolute bit offset of the block mark within the
+	 * ECC-based data. We can now compute the byte offset and the bit
+	 * offset within the byte.
+	 */
+	geo->block_mark_byte_offset = block_mark_bit_offset / 8;
+	geo->block_mark_bit_offset  = block_mark_bit_offset % 8;
+
+	return 0;
+}
+
+struct dma_chan *get_dma_chan(struct gpmi_nand_data *this)
+{
+	int chip = this->mil.current_chip;
+
+	BUG_ON(chip < 0);
+	return this->dma_chans[chip];
+}
+
+/* Can we use the upper's buffer directly for DMA? */
+void prepare_data_dma(struct gpmi_nand_data *this, enum dma_data_direction dr)
+{
+	struct mil *mil = &this->mil;
+	struct scatterlist *sgl = &mil->data_sgl;
+	int ret;
+
+	mil->direct_dma_map_ok = true;
+
+	/* first try to map the upper buffer directly */
+	sg_init_one(sgl, mil->upper_buf, mil->upper_len);
+	ret = dma_map_sg(this->dev, sgl, 1, dr);
+	if (ret == 0) {
+		/* We have to use our own DMA buffer. */
+		sg_init_one(sgl, mil->data_buffer_dma, PAGE_SIZE);
+
+		if (dr == DMA_TO_DEVICE)
+			memcpy(mil->data_buffer_dma, mil->upper_buf,
+				mil->upper_len);
+
+		ret = dma_map_sg(this->dev, sgl, 1, dr);
+		BUG_ON(ret == 0);
+
+		mil->direct_dma_map_ok = false;
+	}
+}
+
+/* This will be called after the DMA operation is finished. */
+static void dma_irq_callback(void *param)
+{
+	struct gpmi_nand_data *this = param;
+	struct mil *mil = &this->mil;
+	struct completion *dma_c = &this->dma_done;
+
+	complete(dma_c);
+
+	switch (this->dma_type) {
+	case DMA_FOR_COMMAND:
+		dma_unmap_sg(this->dev, &mil->cmd_sgl, 1, DMA_TO_DEVICE);
+		break;
+
+	case DMA_FOR_READ_DATA:
+		dma_unmap_sg(this->dev, &mil->data_sgl, 1, DMA_FROM_DEVICE);
+		if (mil->direct_dma_map_ok == false)
+			memcpy(mil->upper_buf, mil->data_buffer_dma,
+				mil->upper_len);
+		break;
+
+	case DMA_FOR_WRITE_DATA:
+		dma_unmap_sg(this->dev, &mil->data_sgl, 1, DMA_TO_DEVICE);
+		break;
+
+	case DMA_FOR_READ_ECC_PAGE:
+	case DMA_FOR_WRITE_ECC_PAGE:
+		/* We have to wait the BCH interrupt to finish. */
+		break;
+
+	default:
+		BUG();
+	}
+}
+
+int start_dma_without_bch_irq(struct gpmi_nand_data *this,
+				struct dma_async_tx_descriptor *desc)
+{
+	struct completion *dma_c = &this->dma_done;
+	int err;
+
+	init_completion(dma_c);
+
+	desc->callback		= dma_irq_callback;
+	desc->callback_param	= this;
+	dmaengine_submit(desc);
+
+	/* Wait for the interrupt from the DMA block. */
+	err = wait_for_completion_timeout(dma_c, msecs_to_jiffies(1000));
+	err = (!err) ? -ETIMEDOUT : 0;
+	if (err) {
+		pr_info("DMA timeout, last DMA :%d\n", this->last_dma_type);
+		if (gpmi_debug & GPMI_DEBUG_CRAZY) {
+			gpmi_show_regs(this);
+			panic("-----------DMA FAILED------------------");
+		}
+	}
+	return err;
+}
+
+/*
+ * This function is used in BCH reading or BCH writing pages.
+ * It will wait for the BCH interrupt as long as ONE second.
+ * Actually, we must wait for two interrupts :
+ *	[1] firstly the DMA interrupt and
+ *	[2] secondly the BCH interrupt.
+ *
+ * @this:	Per-device data structure.
+ * @desc:	DMA channel
+ */
+int start_dma_with_bch_irq(struct gpmi_nand_data *this,
+			struct dma_async_tx_descriptor *desc)
+{
+	int err;
+
+	/* Prepare to receive an interrupt from the BCH block. */
+	init_completion(&this->bch_done);
+
+	/* start the DMA */
+	start_dma_without_bch_irq(this, desc);
+
+	/* Wait for the interrupt from the BCH block. */
+	err = wait_for_completion_timeout(&this->bch_done,
+					msecs_to_jiffies(1000));
+	err = (!err) ? -ETIMEDOUT : 0;
+	if (err)
+		pr_info("bch timeout!!!\n");
+	return err;
+}
+
+static int __devinit acquire_register_block(struct gpmi_nand_data *this,
+			const char *resource_name, void **reg_block_base)
+{
+	struct platform_device *pdev = this->pdev;
+	struct resource *r;
+	void *p;
+
+	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, resource_name);
+	if (!r) {
+		pr_info("Can't get resource for %s\n", resource_name);
+		return -ENXIO;
+	}
+
+	/* remap the register block */
+	p = ioremap(r->start, resource_size(r));
+	if (!p) {
+		pr_info("Can't remap %s\n", resource_name);
+		return -ENOMEM;
+	}
+
+	*reg_block_base = p;
+	return 0;
+}
+
+static void release_register_block(struct gpmi_nand_data *this,
+				void *reg_block_base)
+{
+	iounmap(reg_block_base);
+}
+
+static int __devinit acquire_interrupt(struct gpmi_nand_data *this,
+			const char *resource_name,
+			irq_handler_t interrupt_handler, int *lno, int *hno)
+{
+	struct platform_device *pdev = this->pdev;
+	struct resource *r;
+	int err;
+
+	r = platform_get_resource_byname(pdev, IORESOURCE_IRQ, resource_name);
+	if (!r) {
+		pr_info("Can't get resource for %s\n", resource_name);
+		return -ENXIO;
+	}
+
+	BUG_ON(r->start != r->end);
+	err = request_irq(r->start, interrupt_handler, 0, resource_name, this);
+	if (err) {
+		pr_info("Can't own %s\n", resource_name);
+		return err;
+	}
+
+	*lno = r->start;
+	*hno = r->end;
+	return 0;
+}
+
+static void release_interrupt(struct gpmi_nand_data *this,
+			int low_interrupt_number, int high_interrupt_number)
+{
+	int i;
+	for (i = low_interrupt_number; i <= high_interrupt_number; i++)
+		free_irq(i, this);
+}
+
+static bool gpmi_dma_filter(struct dma_chan *chan, void *param)
+{
+	struct gpmi_nand_data *this = param;
+	struct resource *r = this->private;
+
+	if (!mxs_dma_is_apbh(chan))
+		return false;
+	/*
+	 * only catch the GPMI dma channels :
+	 *	for mx23 :	MX23_DMA_GPMI0 ~ MX23_DMA_GPMI3
+	 *		(These four channels share the same IRQ!)
+	 *
+	 *	for mx28 :	MX28_DMA_GPMI0 ~ MX28_DMA_GPMI7
+	 *		(These eight channels share the same IRQ!)
+	 */
+	if (r->start <= chan->chan_id && chan->chan_id <= r->end) {
+		chan->private = &this->dma_data;
+		return true;
+	}
+	return false;
+}
+
+static void release_dma_channels(struct gpmi_nand_data *this)
+{
+	unsigned int i;
+	for (i = 0; i < DMA_CHANS; i++)
+		if (this->dma_chans[i]) {
+			dma_release_channel(this->dma_chans[i]);
+			this->dma_chans[i] = NULL;
+		}
+}
+
+static int __devinit acquire_dma_channels(struct gpmi_nand_data *this,
+				const char *resource_name,
+				unsigned *low_channel, unsigned *high_channel)
+{
+	struct platform_device *pdev = this->pdev;
+	struct gpmi_nand_platform_data *pdata = this->pdata;
+	struct resource *r, *r_dma;
+	unsigned int i;
+
+	r = platform_get_resource_byname(pdev, IORESOURCE_DMA, resource_name);
+	r_dma = platform_get_resource_byname(pdev, IORESOURCE_IRQ,
+					GPMI_NAND_DMA_INTERRUPT_RES_NAME);
+	if (!r || !r_dma) {
+		pr_info("Can't get resource for DMA\n");
+		return -ENXIO;
+	}
+
+	/* used in gpmi_dma_filter() */
+	this->private = r;
+
+	for (i = r->start; i <= r->end; i++) {
+		struct dma_chan *dma_chan;
+		dma_cap_mask_t mask;
+
+		if (i - r->start >= pdata->max_chip_count)
+			break;
+
+		dma_cap_zero(mask);
+		dma_cap_set(DMA_SLAVE, mask);
+
+		/* get the DMA interrupt */
+		if (r_dma->start == r_dma->end) {
+			/* only register the first. */
+			if (i == r->start)
+				this->dma_data.chan_irq = r_dma->start;
+			else
+				this->dma_data.chan_irq = NO_IRQ;
+		} else
+			this->dma_data.chan_irq = r_dma->start + (i - r->start);
+
+		dma_chan = dma_request_channel(mask, gpmi_dma_filter, this);
+		if (!dma_chan)
+			goto acquire_err;
+
+		/* fill the first empty item */
+		this->dma_chans[i - r->start] = dma_chan;
+	}
+
+	*low_channel  = r->start;
+	*high_channel = i;
+	return 0;
+
+acquire_err:
+	pr_info("Can't acquire DMA channel %u\n", i);
+	release_dma_channels(this);
+	return -EINVAL;
+}
+
+static int __devinit acquire_resources(struct gpmi_nand_data *this)
+{
+	struct resources *r = &this->resources;
+	int error;
+
+	/* Attempt to acquire the GPMI register block. */
+	error = acquire_register_block(this,
+				GPMI_NAND_GPMI_REGS_ADDR_RES_NAME,
+				&r->gpmi_regs);
+	if (error)
+		goto exit_gpmi_regs;
+
+	/* Attempt to acquire the BCH register block. */
+	error = acquire_register_block(this,
+				GPMI_NAND_BCH_REGS_ADDR_RES_NAME,
+				&r->bch_regs);
+	if (error)
+		goto exit_bch_regs;
+
+	/* Attempt to acquire the BCH interrupt. */
+	error = acquire_interrupt(this,
+				GPMI_NAND_BCH_INTERRUPT_RES_NAME,
+				bch_irq,
+				&r->bch_low_interrupt,
+				&r->bch_high_interrupt);
+	if (error)
+		goto exit_bch_interrupt;
+
+	/* Attempt to acquire the DMA channels. */
+	error = acquire_dma_channels(this,
+				GPMI_NAND_DMA_CHANNELS_RES_NAME,
+				&r->dma_low_channel,
+				&r->dma_high_channel);
+	if (error)
+		goto exit_dma_channels;
+
+	/* Attempt to acquire our clock. */
+	r->clock = clk_get(&this->pdev->dev, NULL);
+	if (IS_ERR(r->clock)) {
+		pr_info("can not get the clock\n");
+		error = -ENOENT;
+		goto exit_clock;
+	}
+	return 0;
+
+exit_clock:
+	release_dma_channels(this);
+exit_dma_channels:
+	release_interrupt(this, r->bch_low_interrupt, r->bch_high_interrupt);
+exit_bch_interrupt:
+	release_register_block(this, r->bch_regs);
+exit_bch_regs:
+	release_register_block(this, r->gpmi_regs);
+exit_gpmi_regs:
+	return error;
+}
+
+static void release_resources(struct gpmi_nand_data *this)
+{
+	struct resources *r = &this->resources;
+
+	clk_put(r->clock);
+	release_register_block(this, r->gpmi_regs);
+	release_register_block(this, r->bch_regs);
+	release_interrupt(this, r->bch_low_interrupt, r->bch_low_interrupt);
+	release_dma_channels(this);
+}
+
+static int __devinit init_hardware(struct gpmi_nand_data *this)
+{
+	int error;
+
+	/*
+	 * This structure contains the "safe" GPMI timing that should succeed
+	 * with any NAND Flash device
+	 * (although, with less-than-optimal performance).
+	 */
+	struct nand_timing  safe_timing = {
+		.data_setup_in_ns        = 80,
+		.data_hold_in_ns         = 60,
+		.address_setup_in_ns     = 25,
+		.gpmi_sample_delay_in_ns =  6,
+		.tREA_in_ns              = -1,
+		.tRLOH_in_ns             = -1,
+		.tRHOH_in_ns             = -1,
+	};
+
+	/* Initialize the hardwares. */
+	error = gpmi_init(this);
+	if (error)
+		return error;
+
+	this->timing = safe_timing;
+	return 0;
+}
+
+/* Creates/Removes sysfs files for this device.*/
+static void manage_sysfs_files(struct gpmi_nand_data *this, int create)
+{
+	struct device *dev = this->dev;
+	struct device_attribute **attr;
+	unsigned int i;
+	int error;
+
+	for (i = 0, attr = device_attributes;
+			i < ARRAY_SIZE(device_attributes); i++, attr++) {
+
+		if (create) {
+			error = device_create_file(dev, *attr);
+			if (error) {
+				while (--attr >= device_attributes)
+					device_remove_file(dev, *attr);
+				return;
+			}
+		} else {
+			device_remove_file(dev, *attr);
+		}
+	}
+}
+
+static int read_page_prepare(struct gpmi_nand_data *this,
+			void *destination, unsigned length,
+			void *alt_virt, dma_addr_t alt_phys, unsigned alt_size,
+			void **use_virt, dma_addr_t *use_phys)
+{
+	struct device *dev = this->dev;
+
+	if (virt_addr_valid(destination)) {
+		dma_addr_t dest_phys;
+
+		dest_phys = dma_map_single(dev, destination,
+						length, DMA_FROM_DEVICE);
+		if (dma_mapping_error(dev, dest_phys)) {
+			if (alt_size < length) {
+				pr_info("Alternate buffer is too small\n");
+				return -ENOMEM;
+			}
+			goto map_failed;
+		}
+		*use_virt = destination;
+		*use_phys = dest_phys;
+		this->mil.direct_dma_map_ok = true;
+		return 0;
+	}
+
+map_failed:
+	*use_virt = alt_virt;
+	*use_phys = alt_phys;
+	this->mil.direct_dma_map_ok = false;
+	return 0;
+}
+
+static inline void read_page_end(struct gpmi_nand_data *this,
+			void *destination, unsigned length,
+			void *alt_virt, dma_addr_t alt_phys, unsigned alt_size,
+			void *used_virt, dma_addr_t used_phys)
+{
+	if (this->mil.direct_dma_map_ok)
+		dma_unmap_single(this->dev, used_phys, length, DMA_FROM_DEVICE);
+}
+
+static inline void read_page_swap_end(struct gpmi_nand_data *this,
+			void *destination, unsigned length,
+			void *alt_virt, dma_addr_t alt_phys, unsigned alt_size,
+			void *used_virt, dma_addr_t used_phys)
+{
+	if (!this->mil.direct_dma_map_ok)
+		memcpy(destination, alt_virt, length);
+}
+
+static int send_page_prepare(struct gpmi_nand_data *this,
+			const void *source, unsigned length,
+			void *alt_virt, dma_addr_t alt_phys, unsigned alt_size,
+			const void **use_virt, dma_addr_t *use_phys)
+{
+	struct device *dev = this->dev;
+
+	if (virt_addr_valid(source)) {
+		dma_addr_t source_phys;
+
+		source_phys = dma_map_single(dev, (void *)source, length,
+						DMA_TO_DEVICE);
+		if (dma_mapping_error(dev, source_phys)) {
+			if (alt_size < length) {
+				pr_info("Alternate buffer is too small\n");
+				return -ENOMEM;
+			}
+			goto map_failed;
+		}
+		*use_virt = source;
+		*use_phys = source_phys;
+		return 0;
+	}
+map_failed:
+	/*
+	 * Copy the content of the source buffer into the alternate
+	 * buffer and set up the return values accordingly.
+	 */
+	memcpy(alt_virt, source, length);
+
+	*use_virt = alt_virt;
+	*use_phys = alt_phys;
+	return 0;
+}
+
+static void send_page_end(struct gpmi_nand_data *this,
+			const void *source, unsigned length,
+			void *alt_virt, dma_addr_t alt_phys, unsigned alt_size,
+			const void *used_virt, dma_addr_t used_phys)
+{
+	struct device *dev = this->dev;
+	if (used_virt == source)
+		dma_unmap_single(dev, used_phys, length, DMA_TO_DEVICE);
+}
+
+static void mil_free_dma_buffer(struct gpmi_nand_data *this)
+{
+	struct device *dev = this->dev;
+	struct mil *mil	= &this->mil;
+
+	if (mil->page_buffer_virt && virt_addr_valid(mil->page_buffer_virt))
+		dma_free_coherent(dev, mil->page_buffer_size,
+					mil->page_buffer_virt,
+					mil->page_buffer_phys);
+	kfree(mil->cmd_buffer);
+	kfree(mil->data_buffer_dma);
+
+	mil->cmd_buffer		= NULL;
+	mil->data_buffer_dma	= NULL;
+	mil->page_buffer_virt	= NULL;
+	mil->page_buffer_size	=  0;
+}
+
+/* Allocate the DMA buffers */
+static int mil_alloc_dma_buffer(struct gpmi_nand_data *this)
+{
+	struct bch_geometry *geo = &this->bch_geometry;
+	struct device *dev = this->dev;
+	struct mil *mil = &this->mil;
+
+	/* [1] Allocate a command buffer. PAGE_SIZE is enough. */
+	mil->cmd_buffer = kzalloc(PAGE_SIZE, GFP_DMA);
+	if (mil->cmd_buffer == NULL)
+		goto error_alloc;
+
+	/* [2] Allocate a read/write data buffer. PAGE_SIZE is enough. */
+	mil->data_buffer_dma = kzalloc(PAGE_SIZE, GFP_DMA);
+	if (mil->data_buffer_dma == NULL)
+		goto error_alloc;
+
+	/*
+	 * [3] Allocate the page buffer.
+	 *
+	 * Both the payload buffer and the auxiliary buffer must appear on
+	 * 32-bit boundaries. We presume the size of the payload buffer is a
+	 * power of two and is much larger than four, which guarantees the
+	 * auxiliary buffer will appear on a 32-bit boundary.
+	 */
+	mil->page_buffer_size = geo->payload_size_in_bytes +
+				geo->auxiliary_size_in_bytes;
+
+	mil->page_buffer_virt = dma_alloc_coherent(dev, mil->page_buffer_size,
+					&mil->page_buffer_phys, GFP_DMA);
+	if (!mil->page_buffer_virt)
+		goto error_alloc;
+
+
+	/* Slice up the page buffer. */
+	mil->payload_virt = mil->page_buffer_virt;
+	mil->payload_phys = mil->page_buffer_phys;
+	mil->auxiliary_virt = mil->payload_virt + geo->payload_size_in_bytes;
+	mil->auxiliary_phys = mil->payload_phys + geo->payload_size_in_bytes;
+	return 0;
+
+error_alloc:
+	mil_free_dma_buffer(this);
+	pr_info("allocate DMA buffer error!!\n");
+	return -ENOMEM;
+}
+
+static void mil_cmd_ctrl(struct mtd_info *mtd, int data, unsigned int ctrl)
+{
+	struct nand_chip *nand = mtd->priv;
+	struct gpmi_nand_data *this = nand->priv;
+	struct mil *mil = &this->mil;
+	int error;
+
+	/*
+	 * Every operation begins with a command byte and a series of zero or
+	 * more address bytes. These are distinguished by either the Address
+	 * Latch Enable (ALE) or Command Latch Enable (CLE) signals being
+	 * asserted. When MTD is ready to execute the command, it will deassert
+	 * both latch enables.
+	 *
+	 * Rather than run a separate DMA operation for every single byte, we
+	 * queue them up and run a single DMA operation for the entire series
+	 * of command and data bytes. NAND_CMD_NONE means the END of the queue.
+	 */
+	if ((ctrl & (NAND_ALE | NAND_CLE))) {
+		if (data != NAND_CMD_NONE)
+			mil->cmd_buffer[mil->command_length++] = data;
+		return;
+	}
+
+	if (!mil->command_length)
+		return;
+
+	error = gpmi_send_command(this);
+	if (error)
+		pr_info("Chip: %u, Error %d\n", mil->current_chip, error);
+
+	mil->command_length = 0;
+}
+
+static int mil_dev_ready(struct mtd_info *mtd)
+{
+	struct nand_chip *nand = mtd->priv;
+	struct gpmi_nand_data *this = nand->priv;
+	struct mil *mil = &this->mil;
+
+	return gpmi_is_ready(this, mil->current_chip);
+}
+
+static void mil_select_chip(struct mtd_info *mtd, int chip)
+{
+	struct nand_chip *nand = mtd->priv;
+	struct gpmi_nand_data *this = nand->priv;
+	struct mil *mil = &this->mil;
+
+	if ((mil->current_chip < 0) && (chip >= 0))
+		gpmi_begin(this);
+	else if ((mil->current_chip >= 0) && (chip < 0))
+		gpmi_end(this);
+	else
+		;
+
+	mil->current_chip = chip;
+}
+
+static void mil_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
+{
+	struct nand_chip *nand = mtd->priv;
+	struct gpmi_nand_data *this = nand->priv;
+	struct mil *mil = &this->mil;
+
+	logio(GPMI_DEBUG_READ);
+	/* save the info in mil{} for future */
+	mil->upper_buf	= buf;
+	mil->upper_len	= len;
+
+	gpmi_read_data(this);
+}
+
+static void mil_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
+{
+	struct nand_chip *nand = mtd->priv;
+	struct gpmi_nand_data *this = nand->priv;
+	struct mil *mil = &this->mil;
+
+	logio(GPMI_DEBUG_WRITE);
+	/* save the info in mil{} for future */
+	mil->upper_buf	= (uint8_t *)buf;
+	mil->upper_len	= len;
+
+	gpmi_send_data(this);
+}
+
+static uint8_t mil_read_byte(struct mtd_info *mtd)
+{
+	struct nand_chip *nand = mtd->priv;
+	struct gpmi_nand_data *this = nand->priv;
+	struct mil *mil = &this->mil;
+	uint8_t *buf = mil->data_buffer_dma;
+
+	mil_read_buf(mtd, buf, 1);
+	return buf[0];
+}
+
+/**
+ * mil_handle_block_mark_swapping() - Handles block mark swapping.
+ *
+ * Note that, when this function is called, it doesn't know whether it's
+ * swapping the block mark, or swapping it *back* -- but it doesn't matter
+ * because the the operation is the same.
+ *
+ * @this:       Per-device data.
+ * @payload:    A pointer to the payload buffer.
+ * @auxiliary:  A pointer to the auxiliary buffer.
+ */
+static void mil_handle_block_mark_swapping(struct gpmi_nand_data *this,
+						void *payload, void *auxiliary)
+{
+	struct bch_geometry *nfc_geo = &this->bch_geometry;
+	unsigned char *p;
+	unsigned char *a;
+	unsigned int  bit;
+	unsigned char mask;
+	unsigned char from_data;
+	unsigned char from_oob;
+
+	/* Check if we're doing block mark swapping. */
+	if (!this->swap_block_mark)
+		return;
+
+	/*
+	 * If control arrives here, we're swapping. Make some convenience
+	 * variables.
+	 */
+	bit = nfc_geo->block_mark_bit_offset;
+	p   = payload + nfc_geo->block_mark_byte_offset;
+	a   = auxiliary;
+
+	/*
+	 * Get the byte from the data area that overlays the block mark. Since
+	 * the ECC engine applies its own view to the bits in the page, the
+	 * physical block mark won't (in general) appear on a byte boundary in
+	 * the data.
+	 */
+	from_data = (p[0] >> bit) | (p[1] << (8 - bit));
+
+	/* Get the byte from the OOB. */
+	from_oob = a[0];
+
+	/* Swap them. */
+	a[0] = from_data;
+
+	mask = (0x1 << bit) - 1;
+	p[0] = (p[0] & mask) | (from_oob << bit);
+
+	mask = ~0 << bit;
+	p[1] = (p[1] & mask) | (from_oob >> (8 - bit));
+}
+
+static int mil_ecc_read_page(struct mtd_info *mtd, struct nand_chip *nand,
+				uint8_t *buf, int page)
+{
+	struct gpmi_nand_data *this = nand->priv;
+	struct bch_geometry *nfc_geo = &this->bch_geometry;
+	struct mil *mil = &this->mil;
+	void          *payload_virt;
+	dma_addr_t    payload_phys;
+	void          *auxiliary_virt;
+	dma_addr_t    auxiliary_phys;
+	unsigned int  i;
+	unsigned char *status;
+	unsigned int  failed;
+	unsigned int  corrected;
+	int           error;
+
+	logio(GPMI_DEBUG_ECC_READ);
+	error = read_page_prepare(this, buf, mtd->writesize,
+					mil->payload_virt, mil->payload_phys,
+					nfc_geo->payload_size_in_bytes,
+					&payload_virt, &payload_phys);
+	if (error) {
+		pr_info("Inadequate DMA buffer\n");
+		error = -ENOMEM;
+		return error;
+	}
+	auxiliary_virt = mil->auxiliary_virt;
+	auxiliary_phys = mil->auxiliary_phys;
+
+	/* go! */
+	error = gpmi_read_page(this, payload_phys, auxiliary_phys);
+	read_page_end(this, buf, mtd->writesize,
+			mil->payload_virt, mil->payload_phys,
+			nfc_geo->payload_size_in_bytes,
+			payload_virt, payload_phys);
+	if (error) {
+		pr_info("Error in ECC-based read: %d\n", error);
+		goto exit_nfc;
+	}
+
+	/* handle the block mark swapping */
+	mil_handle_block_mark_swapping(this, payload_virt, auxiliary_virt);
+
+	/* Loop over status bytes, accumulating ECC status. */
+	failed		= 0;
+	corrected	= 0;
+	status		= auxiliary_virt + nfc_geo->auxiliary_status_offset;
+
+	for (i = 0; i < nfc_geo->ecc_chunk_count; i++, status++) {
+		if ((*status == STATUS_GOOD) || (*status == STATUS_ERASED))
+			continue;
+
+		if (*status == STATUS_UNCORRECTABLE) {
+			failed++;
+			continue;
+		}
+		corrected += *status;
+	}
+
+	/*
+	 * Propagate ECC status to the owning MTD only when failed or
+	 * corrected times nearly reaches our ECC correction threshold.
+	 */
+	if (failed || corrected >= (nfc_geo->ecc_strength - 1)) {
+		mtd->ecc_stats.failed    += failed;
+		mtd->ecc_stats.corrected += corrected;
+	}
+
+	/*
+	 * It's time to deliver the OOB bytes. See mil_ecc_read_oob() for
+	 * details about our policy for delivering the OOB.
+	 *
+	 * We fill the caller's buffer with set bits, and then copy the block
+	 * mark to th caller's buffer. Note that, if block mark swapping was
+	 * necessary, it has already been done, so we can rely on the first
+	 * byte of the auxiliary buffer to contain the block mark.
+	 */
+	memset(nand->oob_poi, ~0, mtd->oobsize);
+	nand->oob_poi[0] = ((uint8_t *) auxiliary_virt)[0];
+
+	read_page_swap_end(this, buf, mtd->writesize,
+			mil->payload_virt, mil->payload_phys,
+			nfc_geo->payload_size_in_bytes,
+			payload_virt, payload_phys);
+exit_nfc:
+	return error;
+}
+
+static void mil_ecc_write_page(struct mtd_info *mtd,
+				struct nand_chip *nand, const uint8_t *buf)
+{
+	struct gpmi_nand_data *this = nand->priv;
+	struct bch_geometry *nfc_geo = &this->bch_geometry;
+	struct mil *mil = &this->mil;
+	const void *payload_virt;
+	dma_addr_t payload_phys;
+	const void *auxiliary_virt;
+	dma_addr_t auxiliary_phys;
+	int        error;
+
+	logio(GPMI_DEBUG_ECC_WRITE);
+	if (this->swap_block_mark) {
+		/*
+		 * If control arrives here, we're doing block mark swapping.
+		 * Since we can't modify the caller's buffers, we must copy them
+		 * into our own.
+		 */
+		memcpy(mil->payload_virt, buf, mtd->writesize);
+		payload_virt = mil->payload_virt;
+		payload_phys = mil->payload_phys;
+
+		memcpy(mil->auxiliary_virt, nand->oob_poi,
+				nfc_geo->auxiliary_size_in_bytes);
+		auxiliary_virt = mil->auxiliary_virt;
+		auxiliary_phys = mil->auxiliary_phys;
+
+		/* Handle block mark swapping. */
+		mil_handle_block_mark_swapping(this,
+				(void *) payload_virt, (void *) auxiliary_virt);
+	} else {
+		/*
+		 * If control arrives here, we're not doing block mark swapping,
+		 * so we can to try and use the caller's buffers.
+		 */
+		error = send_page_prepare(this,
+				buf, mtd->writesize,
+				mil->payload_virt, mil->payload_phys,
+				nfc_geo->payload_size_in_bytes,
+				&payload_virt, &payload_phys);
+		if (error) {
+			pr_info("Inadequate payload DMA buffer\n");
+			return;
+		}
+
+		error = send_page_prepare(this,
+				nand->oob_poi, mtd->oobsize,
+				mil->auxiliary_virt, mil->auxiliary_phys,
+				nfc_geo->auxiliary_size_in_bytes,
+				&auxiliary_virt, &auxiliary_phys);
+		if (error) {
+			pr_info("Inadequate auxiliary DMA buffer\n");
+			goto exit_auxiliary;
+		}
+	}
+
+	/* Ask the NFC. */
+	error = gpmi_send_page(this, payload_phys, auxiliary_phys);
+	if (error)
+		pr_info("Error in ECC-based write: %d\n", error);
+
+	if (!this->swap_block_mark) {
+		send_page_end(this, nand->oob_poi, mtd->oobsize,
+				mil->auxiliary_virt, mil->auxiliary_phys,
+				nfc_geo->auxiliary_size_in_bytes,
+				auxiliary_virt, auxiliary_phys);
+exit_auxiliary:
+		send_page_end(this, buf, mtd->writesize,
+				mil->payload_virt, mil->payload_phys,
+				nfc_geo->payload_size_in_bytes,
+				payload_virt, payload_phys);
+	}
+}
+
+static int mil_hook_block_markbad(struct mtd_info *mtd, loff_t ofs)
+{
+	register struct nand_chip *chip = mtd->priv;
+	struct gpmi_nand_data *this = chip->priv;
+	struct mil *mil = &this->mil;
+	int ret;
+
+	mil->marking_a_bad_block = true;
+	ret = mil->hooked_block_markbad(mtd, ofs);
+	mil->marking_a_bad_block = false;
+	return ret;
+}
+
+/**
+ * mil_ecc_read_oob() - MTD Interface ecc.read_oob().
+ *
+ * There are several places in this driver where we have to handle the OOB and
+ * block marks. This is the function where things are the most complicated, so
+ * this is where we try to explain it all. All the other places refer back to
+ * here.
+ *
+ * These are the rules, in order of decreasing importance:
+ *
+ * 1) Nothing the caller does can be allowed to imperil the block mark, so all
+ *    write operations take measures to protect it.
+ *
+ * 2) In read operations, the first byte of the OOB we return must reflect the
+ *    true state of the block mark, no matter where that block mark appears in
+ *    the physical page.
+ *
+ * 3) ECC-based read operations return an OOB full of set bits (since we never
+ *    allow ECC-based writes to the OOB, it doesn't matter what ECC-based reads
+ *    return).
+ *
+ * 4) "Raw" read operations return a direct view of the physical bytes in the
+ *    page, using the conventional definition of which bytes are data and which
+ *    are OOB. This gives the caller a way to see the actual, physical bytes
+ *    in the page, without the distortions applied by our ECC engine.
+ *
+ *
+ * What we do for this specific read operation depends on two questions:
+ *
+ * 1) Are we doing a "raw" read, or an ECC-based read?
+ *
+ * 2) Are we using block mark swapping or transcription?
+ *
+ * There are four cases, illustrated by the following Karnaugh map:
+ *
+ *                    |           Raw           |         ECC-based       |
+ *       -------------+-------------------------+-------------------------+
+ *                    | Read the conventional   |                         |
+ *                    | OOB at the end of the   |                         |
+ *       Swapping     | page and return it. It  |                         |
+ *                    | contains exactly what   |                         |
+ *                    | we want.                | Read the block mark and |
+ *       -------------+-------------------------+ return it in a buffer   |
+ *                    | Read the conventional   | full of set bits.       |
+ *                    | OOB at the end of the   |                         |
+ *                    | page and also the block |                         |
+ *       Transcribing | mark in the metadata.   |                         |
+ *                    | Copy the block mark     |                         |
+ *                    | into the first byte of  |                         |
+ *                    | the OOB.                |                         |
+ *       -------------+-------------------------+-------------------------+
+ *
+ * Note that we break rule #4 in the Transcribing/Raw case because we're not
+ * giving an accurate view of the actual, physical bytes in the page (we're
+ * overwriting the block mark). That's OK because it's more important to follow
+ * rule #2.
+ *
+ * It turns out that knowing whether we want an "ECC-based" or "raw" read is not
+ * easy. When reading a page, for example, the NAND Flash MTD code calls our
+ * ecc.read_page or ecc.read_page_raw function. Thus, the fact that MTD wants an
+ * ECC-based or raw view of the page is implicit in which function it calls
+ * (there is a similar pair of ECC-based/raw functions for writing).
+ *
+ * Since MTD assumes the OOB is not covered by ECC, there is no pair of
+ * ECC-based/raw functions for reading or or writing the OOB. The fact that the
+ * caller wants an ECC-based or raw view of the page is not propagated down to
+ * this driver.
+ *
+ * @mtd:     A pointer to the owning MTD.
+ * @nand:    A pointer to the owning NAND Flash MTD.
+ * @page:    The page number to read.
+ * @sndcmd:  Indicates this function should send a command to the chip before
+ *           reading the out-of-band bytes. This is only false for small page
+ *           chips that support auto-increment.
+ */
+static int mil_ecc_read_oob(struct mtd_info *mtd, struct nand_chip *nand,
+							int page, int sndcmd)
+{
+	struct gpmi_nand_data *this = nand->priv;
+
+	/* clear the OOB buffer */
+	memset(nand->oob_poi, ~0, mtd->oobsize);
+
+	/* Read out the conventional OOB. */
+	nand->cmdfunc(mtd, NAND_CMD_READ0, mtd->writesize, page);
+	nand->read_buf(mtd, nand->oob_poi, mtd->oobsize);
+
+	/*
+	 * Now, we want to make sure the block mark is correct. In the
+	 * Swapping/Raw case, we already have it. Otherwise, we need to
+	 * explicitly read it.
+	 */
+	if (!this->swap_block_mark) {
+		/* Read the block mark into the first byte of the OOB buffer. */
+		nand->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
+		nand->oob_poi[0] = nand->read_byte(mtd);
+	}
+
+	/*
+	 * Return true, indicating that the next call to this function must send
+	 * a command.
+	 */
+	return true;
+}
+
+static int mil_ecc_write_oob(struct mtd_info *mtd,
+				struct nand_chip *nand, int page)
+{
+	struct gpmi_nand_data *this = nand->priv;
+	struct device *dev = this->dev;
+	struct mil *mil	= &this->mil;
+	uint8_t *block_mark;
+	int block_mark_column;
+	int status;
+	int error = 0;
+
+	/* Only marking a block bad is permitted to write the OOB. */
+	if (!mil->marking_a_bad_block) {
+		dev_emerg(dev, "This driver doesn't support writing the OOB\n");
+		WARN_ON(1);
+		error = -EIO;
+		goto exit;
+	}
+
+	if (this->swap_block_mark)
+		block_mark_column = mtd->writesize;
+	else
+		block_mark_column = 0;
+
+	/* Write the block mark. */
+	block_mark = mil->data_buffer_dma;
+	block_mark[0] = 0; /* bad block marker */
+
+	nand->cmdfunc(mtd, NAND_CMD_SEQIN, block_mark_column, page);
+	nand->write_buf(mtd, block_mark, 1);
+	nand->cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1);
+
+	status = nand->waitfunc(mtd, nand);
+
+	/* Check if it worked. */
+	if (status & NAND_STATUS_FAIL)
+		error = -EIO;
+exit:
+	return error;
+}
+
+/**
+ * mil_block_bad - Claims all blocks are good.
+ *
+ * In principle, this function is *only* called when the NAND Flash MTD system
+ * isn't allowed to keep an in-memory bad block table, so it is forced to ask
+ * the driver for bad block information.
+ *
+ * In fact, we permit the NAND Flash MTD system to have an in-memory BBT, so
+ * this function is *only* called when we take it away.
+ *
+ * We take away the in-memory BBT when the user sets the "ignorebad" parameter,
+ * which indicates that all blocks should be reported good.
+ *
+ * Thus, this function is only called when we want *all* blocks to look good,
+ * so it *always* return success.
+ *
+ * @mtd:      Ignored.
+ * @ofs:      Ignored.
+ * @getchip:  Ignored.
+ */
+static int mil_block_bad(struct mtd_info *mtd, loff_t ofs, int getchip)
+{
+	return 0;
+}
+
+static int __devinit nand_boot_set_geometry(struct gpmi_nand_data *this)
+{
+	struct boot_rom_geometry *geometry = &this->rom_geometry;
+
+	/*
+	 * Set the boot block stride size.
+	 *
+	 * In principle, we should be reading this from the OTP bits, since
+	 * that's where the ROM is going to get it. In fact, we don't have any
+	 * way to read the OTP bits, so we go with the default and hope for the
+	 * best.
+	 */
+	geometry->stride_size_in_pages = 64;
+
+	/*
+	 * Set the search area stride exponent.
+	 *
+	 * In principle, we should be reading this from the OTP bits, since
+	 * that's where the ROM is going to get it. In fact, we don't have any
+	 * way to read the OTP bits, so we go with the default and hope for the
+	 * best.
+	 */
+	geometry->search_area_stride_exponent = 2;
+
+	if (gpmi_debug & GPMI_DEBUG_INIT)
+		pr_info("stride size in page : %d, search areas : %d\n",
+			geometry->stride_size_in_pages,
+			geometry->search_area_stride_exponent);
+	return 0;
+}
+
+static const char  *fingerprint = "STMP";
+static int __devinit mx23_check_transcription_stamp(struct gpmi_nand_data *this)
+{
+	struct boot_rom_geometry *rom_geo = &this->rom_geometry;
+	struct mil *mil = &this->mil;
+	struct mtd_info *mtd = &mil->mtd;
+	struct nand_chip *nand = &mil->nand;
+	unsigned int search_area_size_in_strides;
+	unsigned int stride;
+	unsigned int page;
+	loff_t byte;
+	uint8_t *buffer = nand->buffers->databuf;
+	int saved_chip_number;
+	int found_an_ncb_fingerprint = false;
+
+	/* Compute the number of strides in a search area. */
+	search_area_size_in_strides = 1 << rom_geo->search_area_stride_exponent;
+
+	/* Select chip 0. */
+	saved_chip_number = mil->current_chip;
+	nand->select_chip(mtd, 0);
+
+	/*
+	 * Loop through the first search area, looking for the NCB fingerprint.
+	 */
+	pr_info("Scanning for an NCB fingerprint...\n");
+
+	for (stride = 0; stride < search_area_size_in_strides; stride++) {
+		/* Compute the page and byte addresses. */
+		page = stride * rom_geo->stride_size_in_pages;
+		byte = page   * mtd->writesize;
+
+		pr_info("  Looking for a fingerprint in page 0x%x\n", page);
+
+		/*
+		 * Read the NCB fingerprint. The fingerprint is four bytes long
+		 * and starts in the 12th byte of the page.
+		 */
+		nand->cmdfunc(mtd, NAND_CMD_READ0, 12, page);
+		nand->read_buf(mtd, buffer, strlen(fingerprint));
+
+		/* Look for the fingerprint. */
+		if (!memcmp(buffer, fingerprint, strlen(fingerprint))) {
+			found_an_ncb_fingerprint = true;
+			break;
+		}
+
+	}
+
+	/* Deselect chip 0. */
+	nand->select_chip(mtd, saved_chip_number);
+
+	if (found_an_ncb_fingerprint)
+		pr_info("  Found a fingerprint\n");
+	else
+		pr_info("  No fingerprint found\n");
+	return found_an_ncb_fingerprint;
+}
+
+/* Writes a transcription stamp. */
+static int __devinit mx23_write_transcription_stamp(struct gpmi_nand_data *this)
+{
+	struct device *dev = this->dev;
+	struct boot_rom_geometry *rom_geo = &this->rom_geometry;
+	struct mil *mil = &this->mil;
+	struct mtd_info *mtd = &mil->mtd;
+	struct nand_chip *nand = &mil->nand;
+	unsigned int block_size_in_pages;
+	unsigned int search_area_size_in_strides;
+	unsigned int search_area_size_in_pages;
+	unsigned int search_area_size_in_blocks;
+	unsigned int block;
+	unsigned int stride;
+	unsigned int page;
+	loff_t       byte;
+	uint8_t      *buffer = nand->buffers->databuf;
+	int saved_chip_number;
+	int status;
+
+	/* Compute the search area geometry. */
+	block_size_in_pages = mtd->erasesize / mtd->writesize;
+	search_area_size_in_strides = 1 << rom_geo->search_area_stride_exponent;
+	search_area_size_in_pages = search_area_size_in_strides *
+					rom_geo->stride_size_in_pages;
+	search_area_size_in_blocks =
+		  (search_area_size_in_pages + (block_size_in_pages - 1)) /
+				    block_size_in_pages;
+
+	pr_info("-------------------------------------------\n");
+	pr_info("Search Area Geometry\n");
+	pr_info("-------------------------------------------\n");
+	pr_info("Search Area in Blocks : %u\n", search_area_size_in_blocks);
+	pr_info("Search Area in Strides: %u\n", search_area_size_in_strides);
+	pr_info("Search Area in Pages  : %u\n", search_area_size_in_pages);
+
+	/* Select chip 0. */
+	saved_chip_number = mil->current_chip;
+	nand->select_chip(mtd, 0);
+
+	/* Loop over blocks in the first search area, erasing them. */
+	pr_info("Erasing the search area...\n");
+
+	for (block = 0; block < search_area_size_in_blocks; block++) {
+		/* Compute the page address. */
+		page = block * block_size_in_pages;
+
+		/* Erase this block. */
+		pr_info("  Erasing block 0x%x\n", block);
+		nand->cmdfunc(mtd, NAND_CMD_ERASE1, -1, page);
+		nand->cmdfunc(mtd, NAND_CMD_ERASE2, -1, -1);
+
+		/* Wait for the erase to finish. */
+		status = nand->waitfunc(mtd, nand);
+		if (status & NAND_STATUS_FAIL)
+			dev_err(dev, "[%s] Erase failed.\n", __func__);
+	}
+
+	/* Write the NCB fingerprint into the page buffer. */
+	memset(buffer, ~0, mtd->writesize);
+	memset(nand->oob_poi, ~0, mtd->oobsize);
+	memcpy(buffer + 12, fingerprint, strlen(fingerprint));
+
+	/* Loop through the first search area, writing NCB fingerprints. */
+	pr_info("Writing NCB fingerprints...\n");
+	for (stride = 0; stride < search_area_size_in_strides; stride++) {
+		/* Compute the page and byte addresses. */
+		page = stride * rom_geo->stride_size_in_pages;
+		byte = page   * mtd->writesize;
+
+		/* Write the first page of the current stride. */
+		pr_info("  Writing an NCB fingerprint in page 0x%x\n", page);
+		nand->cmdfunc(mtd, NAND_CMD_SEQIN, 0x00, page);
+		nand->ecc.write_page_raw(mtd, nand, buffer);
+		nand->cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1);
+
+		/* Wait for the write to finish. */
+		status = nand->waitfunc(mtd, nand);
+		if (status & NAND_STATUS_FAIL)
+			dev_err(dev, "[%s] Write failed.\n", __func__);
+	}
+
+	/* Deselect chip 0. */
+	nand->select_chip(mtd, saved_chip_number);
+	return 0;
+}
+
+static int __devinit mx23_boot_init(struct gpmi_nand_data  *this)
+{
+	struct device *dev = this->dev;
+	struct mil *mil = &this->mil;
+	struct nand_chip *nand = &mil->nand;
+	struct mtd_info *mtd = &mil->mtd;
+	unsigned int block_count;
+	unsigned int block;
+	int     chip;
+	int     page;
+	loff_t  byte;
+	uint8_t block_mark;
+	int     error = 0;
+
+	/*
+	 * If control arrives here, we can't use block mark swapping, which
+	 * means we're forced to use transcription. First, scan for the
+	 * transcription stamp. If we find it, then we don't have to do
+	 * anything -- the block marks are already transcribed.
+	 */
+	if (mx23_check_transcription_stamp(this))
+		return 0;
+
+	/*
+	 * If control arrives here, we couldn't find a transcription stamp, so
+	 * so we presume the block marks are in the conventional location.
+	 */
+	pr_info("Transcribing bad block marks...\n");
+
+	/* Compute the number of blocks in the entire medium. */
+	block_count = nand->chipsize >> nand->phys_erase_shift;
+
+	/*
+	 * Loop over all the blocks in the medium, transcribing block marks as
+	 * we go.
+	 */
+	for (block = 0; block < block_count; block++) {
+		/*
+		 * Compute the chip, page and byte addresses for this block's
+		 * conventional mark.
+		 */
+		chip = block >> (nand->chip_shift - nand->phys_erase_shift);
+		page = block << (nand->phys_erase_shift - nand->page_shift);
+		byte = block <<  nand->phys_erase_shift;
+
+		/* Select the chip. */
+		nand->select_chip(mtd, chip);
+
+		/* Send the command to read the conventional block mark. */
+		nand->cmdfunc(mtd, NAND_CMD_READ0, mtd->writesize, page);
+
+		/* Read the conventional block mark. */
+		block_mark = nand->read_byte(mtd);
+
+		/*
+		 * Check if the block is marked bad. If so, we need to mark it
+		 * again, but this time the result will be a mark in the
+		 * location where we transcribe block marks.
+		 *
+		 * Notice that we have to explicitly set the marking_a_bad_block
+		 * member before we call through the block_markbad function
+		 * pointer in the owning struct nand_chip. If we could call
+		 * though the block_markbad function pointer in the owning
+		 * struct mtd_info, which we have hooked, then this would be
+		 * taken care of for us. Unfortunately, we can't because that
+		 * higher-level code path will do things like consulting the
+		 * in-memory bad block table -- which doesn't even exist yet!
+		 * So, we have to call at a lower level and handle some details
+		 * ourselves.
+		 */
+		if (block_mark != 0xff) {
+			pr_info("Transcribing mark in block %u\n", block);
+			mil->marking_a_bad_block = true;
+			error = nand->block_markbad(mtd, byte);
+			mil->marking_a_bad_block = false;
+			if (error)
+				dev_err(dev, "Failed to mark block bad with "
+							"error %d\n", error);
+		}
+
+		/* Deselect the chip. */
+		nand->select_chip(mtd, -1);
+	}
+
+	/* Write the stamp that indicates we've transcribed the block marks. */
+	mx23_write_transcription_stamp(this);
+	return 0;
+}
+
+static int __devinit nand_boot_init(struct gpmi_nand_data  *this)
+{
+	nand_boot_set_geometry(this);
+
+	/* This is ROM arch-specific initilization before the BBT scanning. */
+	if (GPMI_IS_MX23(this))
+		return mx23_boot_init(this);
+	return 0;
+}
+
+static void show_bch_geometry(struct bch_geometry *geo)
+{
+	pr_info("---------------------------------------\n");
+	pr_info("	BCH Geometry\n");
+	pr_info("---------------------------------------\n");
+	pr_info("ECC Algorithm          : %s\n", geo->ecc_algorithm);
+	pr_info("ECC Strength           : %u\n", geo->ecc_strength);
+	pr_info("Page Size in Bytes     : %u\n", geo->page_size_in_bytes);
+	pr_info("Metadata Size in Bytes : %u\n", geo->metadata_size_in_bytes);
+	pr_info("ECC Chunk Size in Bytes: %u\n", geo->ecc_chunk_size_in_bytes);
+	pr_info("ECC Chunk Count        : %u\n", geo->ecc_chunk_count);
+	pr_info("Payload Size in Bytes  : %u\n", geo->payload_size_in_bytes);
+	pr_info("Auxiliary Size in Bytes: %u\n", geo->auxiliary_size_in_bytes);
+	pr_info("Auxiliary Status Offset: %u\n", geo->auxiliary_status_offset);
+	pr_info("Block Mark Byte Offset : %u\n", geo->block_mark_byte_offset);
+	pr_info("Block Mark Bit Offset  : %u\n", geo->block_mark_bit_offset);
+}
+
+static int __devinit mil_set_geometry(struct gpmi_nand_data *this)
+{
+	struct bch_geometry *geo = &this->bch_geometry;
+	int error;
+
+	/* Free the temporary DMA memory for reading ID. */
+	mil_free_dma_buffer(this);
+
+	/* Set up the NFC geometry which is used by BCH. */
+	error = bch_set_geometry(this);
+	if (error) {
+		pr_info("set geometry error : %d\n", error);
+		return error;
+	}
+	if (gpmi_debug & GPMI_DEBUG_INIT)
+		show_bch_geometry(geo);
+
+	/* Alloc the new DMA buffers according to the pagesize and oobsize */
+	return mil_alloc_dma_buffer(this);
+}
+
+static int mil_pre_bbt_scan(struct gpmi_nand_data  *this)
+{
+	struct nand_chip *nand = &this->mil.nand;
+	struct mtd_info *mtd = &this->mil.mtd;
+	struct nand_ecclayout *layout = nand->ecc.layout;
+	int error;
+
+	/* fix the ECC layout before the scanning */
+	layout->eccbytes          = 0;
+	layout->oobavail          = mtd->oobsize;
+	layout->oobfree[0].offset = 0;
+	layout->oobfree[0].length = mtd->oobsize;
+
+	mtd->oobavail = nand->ecc.layout->oobavail;
+
+	/* Set up swap block-mark, must be set before the mil_set_geometry() */
+	if (GPMI_IS_MX23(this))
+		this->swap_block_mark = false;
+	else
+		this->swap_block_mark = true;
+
+	/* Set up the medium geometry */
+	error = mil_set_geometry(this);
+	if (error)
+		return error;
+
+	/* extra init : enable the TOGGLE or ONFI. */
+
+	/* NAND boot init, depends on the mil_set_geometry(). */
+	return nand_boot_init(this);
+}
+
+static int mil_scan_bbt(struct mtd_info *mtd)
+{
+	struct nand_chip *nand = mtd->priv;
+	struct gpmi_nand_data *this = nand->priv;
+	int error;
+
+	/* Prepare for the BBT scan. */
+	error = mil_pre_bbt_scan(this);
+	if (error)
+		return error;
+
+	/* use the default BBT implementation */
+	return nand_default_bbt(mtd);
+}
+
+static const char *cmd_parse[] = {"cmdlinepart", NULL};
+static int __devinit mil_partitions_init(struct gpmi_nand_data *this)
+{
+	struct gpmi_nand_platform_data *pdata = this->pdata;
+	struct mil *mil = &this->mil;
+	struct mtd_info *mtd = &mil->mtd;
+
+	/* use the command line for simple partitions layout */
+	mil->partition_count = parse_mtd_partitions(mtd, cmd_parse,
+						&mil->partitions, 0);
+	if (mil->partition_count)
+		return mtd_device_register(mtd, mil->partitions,
+					mil->partition_count);
+
+	/* The complicated partitions layout uses this. */
+	if (pdata->partitions && pdata->partition_count > 0)
+		return mtd_device_register(mtd, pdata->partitions,
+					pdata->partition_count);
+	return mtd_device_register(mtd, NULL, 0);
+}
+
+static void mil_partitions_exit(struct gpmi_nand_data *this)
+{
+	struct mil *mil = &this->mil;
+	struct mtd_info *mtd = &mil->mtd;
+
+	mtd_device_unregister(mtd);
+	kfree(mil->partitions);
+	mil->partition_count = 0;
+}
+
+/* Initializes the MTD Interface Layer */
+static int __devinit gpmi_nfc_mil_init(struct gpmi_nand_data *this)
+{
+	struct gpmi_nand_platform_data *pdata = this->pdata;
+	struct mil *mil = &this->mil;
+	struct mtd_info  *mtd = &mil->mtd;
+	struct nand_chip *nand = &mil->nand;
+	int error;
+
+	/* Initialize MIL data */
+	mil->current_chip	= -1;
+	mil->command_length	=  0;
+	mil->page_buffer_virt	=  NULL;
+	mil->page_buffer_size	=  0;
+
+	/* Initialize the MTD data structures */
+	mtd->priv		= nand;
+	mtd->name		= "gpmi-nand";
+	mtd->owner		= THIS_MODULE;
+	nand->priv		= this;
+
+	/* Controls */
+	nand->select_chip	= mil_select_chip;
+	nand->cmd_ctrl		= mil_cmd_ctrl;
+	nand->dev_ready		= mil_dev_ready;
+
+	/*
+	 * Low-level I/O :
+	 *	We don't support a 16-bit NAND Flash bus,
+	 *	so we don't implement read_word.
+	 */
+	nand->read_byte		= mil_read_byte;
+	nand->read_buf		= mil_read_buf;
+	nand->write_buf		= mil_write_buf;
+
+	/* ECC-aware I/O */
+	nand->ecc.read_page	= mil_ecc_read_page;
+	nand->ecc.write_page	= mil_ecc_write_page;
+
+	/* High-level I/O */
+	nand->ecc.read_oob	= mil_ecc_read_oob;
+	nand->ecc.write_oob	= mil_ecc_write_oob;
+
+	/* Bad Block Management */
+	nand->block_bad		= mil_block_bad;
+	nand->scan_bbt		= mil_scan_bbt;
+	nand->badblock_pattern	= &gpmi_bbt_descr;
+
+	/* Disallow partial page writes */
+	nand->options		|= NAND_NO_SUBPAGE_WRITE;
+
+	/*
+	 * Tell the NAND Flash MTD system that we'll be handling ECC with our
+	 * own hardware. It turns out that we still have to fill in the ECC size
+	 * because the MTD code will divide by it -- even though it doesn't
+	 * actually care.
+	 */
+	nand->ecc.mode		= NAND_ECC_HW;
+	nand->ecc.size		= 1;
+
+	/* use our layout */
+	nand->ecc.layout = &mil->oob_layout;
+
+	/* Allocate a temporary DMA buffer for reading ID in the nand_scan() */
+	this->bch_geometry.payload_size_in_bytes	= 1024;
+	this->bch_geometry.auxiliary_size_in_bytes	= 128;
+	error = mil_alloc_dma_buffer(this);
+	if (error)
+		goto exit_dma_allocation;
+
+	printk(KERN_INFO "GPMI-NFC : Scanning for NAND Flash chips...\n");
+	error = nand_scan(mtd, pdata->max_chip_count);
+	if (error) {
+		pr_info("Chip scan failed\n");
+		goto exit_nand_scan;
+	}
+
+	/* Take over the management of the OOB */
+	mil->hooked_block_markbad = mtd->block_markbad;
+	mtd->block_markbad        = mil_hook_block_markbad;
+
+	/* Construct partitions as necessary. */
+	error = mil_partitions_init(this);
+	if (error)
+		goto exit_partitions;
+	return 0;
+
+exit_partitions:
+	nand_release(&mil->mtd);
+exit_nand_scan:
+	mil_free_dma_buffer(this);
+exit_dma_allocation:
+	return error;
+}
+
+void gpmi_nand_mil_exit(struct gpmi_nand_data *this)
+{
+	struct mil *mil = &this->mil;
+
+	mil_partitions_exit(this);
+	nand_release(&mil->mtd);
+	mil_free_dma_buffer(this);
+}
+
+static int __devinit gpmi_nand_probe(struct platform_device *pdev)
+{
+	struct gpmi_nand_platform_data *pdata = pdev->dev.platform_data;
+	struct gpmi_nand_data *this;
+	int error;
+
+	this = kzalloc(sizeof(*this), GFP_KERNEL);
+	if (!this) {
+		pr_info("Failed to allocate per-device memory\n");
+		return -ENOMEM;
+	}
+
+	/* Set up our data structures. */
+	platform_set_drvdata(pdev, this);
+	this->pdev  = pdev;
+	this->dev   = &pdev->dev;
+	this->pdata = pdata;
+
+	/* setup the platform */
+	if (pdata->platform_init) {
+		error = pdata->platform_init();
+		if (error)
+			goto platform_init_error;
+	}
+
+	/* Acquire the resources we need. */
+	error = acquire_resources(this);
+	if (error)
+		goto exit_acquire_resources;
+
+	/* Set up the GPMI/BCH hardware. */
+	error = init_hardware(this);
+	if (error)
+		goto exit_nfc_init;
+
+	/* Initialize the MTD Interface Layer. */
+	error = gpmi_nfc_mil_init(this);
+	if (error)
+		goto exit_mil_init;
+
+	manage_sysfs_files(this, true);
+	return 0;
+
+exit_mil_init:
+exit_nfc_init:
+	release_resources(this);
+platform_init_error:
+exit_acquire_resources:
+	platform_set_drvdata(pdev, NULL);
+	kfree(this);
+	return error;
+}
+
+static int __exit gpmi_nand_remove(struct platform_device *pdev)
+{
+	struct gpmi_nand_data *this = platform_get_drvdata(pdev);
+
+	manage_sysfs_files(this, false);
+	gpmi_nand_mil_exit(this);
+	release_resources(this);
+	platform_set_drvdata(pdev, NULL);
+	kfree(this);
+	return 0;
+}
+
+static const struct platform_device_id gpmi_ids[] = {
+	{
+		.name = "imx23-gpmi-nand",
+		.driver_data = IS_MX23,
+	}, {
+		.name = "imx28-gpmi-nand",
+		.driver_data = IS_MX28,
+	}, {},
+};
+
+/* This structure represents this driver to the platform management system. */
+static struct platform_driver gpmi_nand_driver = {
+	.driver = {
+		.name = "gpmi-nand",
+	},
+	.probe   = gpmi_nand_probe,
+	.remove  = __exit_p(gpmi_nand_remove),
+	.id_table = gpmi_ids,
+};
+
+static int __init gpmi_nand_init(void)
+{
+	int err;
+
+	if (!enable_gpmi_nand)
+		return 0;
+
+	err = platform_driver_register(&gpmi_nand_driver);
+	if (err == 0)
+		printk(KERN_INFO "GPMI NFC driver registered. (IMX)\n");
+	else
+		pr_err("i.MX GPMI NFC driver registration failed\n");
+	return err;
+}
+
+static void __exit gpmi_nand_exit(void)
+{
+	platform_driver_unregister(&gpmi_nand_driver);
+}
+
+static int __init gpmi_nand_setup(char *__unused)
+{
+	enable_gpmi_nand = true;
+	return 1;
+}
+__setup("gpmi_nand", gpmi_nand_setup);
+
+static int __init gpmi_debug_setup(char *__unused)
+{
+	gpmi_debug = GPMI_DEBUG_INIT;
+	enable_gpmi_nand = true;
+	return 1;
+}
+__setup("gpmi_debug_init", gpmi_debug_setup);
+
+module_init(gpmi_nand_init);
+module_exit(gpmi_nand_exit);
+
+MODULE_AUTHOR("Freescale Semiconductor, Inc.");
+MODULE_DESCRIPTION("i.MX GPMI NAND Flash Controller Driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
new file mode 100644
index 0000000..cc1aee1
--- /dev/null
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
@@ -0,0 +1,390 @@
+/*
+ * Freescale GPMI NAND Flash Driver
+ *
+ * Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
+ * Copyright (C) 2008 Embedded Alley Solutions, Inc.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#ifndef __DRIVERS_MTD_NAND_GPMI_NAND_H
+#define __DRIVERS_MTD_NAND_GPMI_NAND_H
+
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/concat.h>
+#include <linux/dmaengine.h>
+#include <asm/sizes.h>
+
+#include <mach/common.h>
+#include <mach/dma.h>
+#include <linux/mtd/gpmi-nand.h>
+#include <mach/system.h>
+#include <mach/clock.h>
+
+/* The collection of resources the driver needs. */
+struct resources {
+	void          *gpmi_regs;
+	void          *bch_regs;
+	unsigned int  bch_low_interrupt;
+	unsigned int  bch_high_interrupt;
+	unsigned int  dma_low_channel;
+	unsigned int  dma_high_channel;
+	struct clk    *clock;
+};
+
+/**
+ * struct mil - State for the MTD Interface Layer.
+ *
+ * @nand:                    The NAND Flash MTD data structure that represents
+ *                           the NAND Flash medium.
+ * @mtd:                     The MTD data structure that represents the NAND
+ *                           Flash medium.
+ * @oob_layout:              A structure that describes how bytes are laid out
+ *                           in the OOB.
+ * @partitions:              A pointer to a set of partitions.
+ * @partition_count:         The number of partitions.
+ * @current_chip:            The chip currently selected by the NAND Fash MTD
+ *                           code. A negative value indicates that no chip is
+ *                           selected.
+ * @command_length:          The length of the command that appears in the
+ *                           command buffer (see cmd_virt, below).
+ * @ignore_bad_block_marks:  Indicates we are ignoring bad block marks.
+ * @saved_bbt:               A saved pointer to the in-memory NAND Flash MTD bad
+ *                           block table. See show_device_ignorebad() for more
+ *                           details.
+ * @marking_a_bad_block:     Indicates the caller is marking a bad block. See
+ *                           mil_ecc_write_oob() for details.
+ * @hooked_block_markbad:    A pointer to the block_markbad() function we
+ *                           we "hooked." See mil_ecc_write_oob() for details.
+ * @upper_buf:               The buffer passed from upper layer.
+ * @upper_len:               The buffer len passed from upper layer.
+ * @direct_dma_map_ok:       Is the direct DMA map is good for the upper_buf?
+ * @cmd_sgl/cmd_buffer:      For NAND command.
+ * @data_sgl/data_buffer_dma:For NAND DATA ops.
+ * @page_buffer_virt:        A pointer to a DMA-coherent buffer we use for
+ *                           reading and writing pages. This buffer includes
+ *                           space for both the payload data and the auxiliary
+ *                           data (including status bytes, but not syndrome
+ *                           bytes).
+ * @page_buffer_phys:        The physical address for the page_buffer_virt
+ *                           buffer.
+ * @page_buffer_size:        The size of the page buffer.
+ * @payload_virt:            A pointer to a location in the page buffer used
+ *                           for payload bytes. The size of this buffer is
+ *                           determined by struct bch_geometry.
+ * @payload_phys:            The physical address for payload_virt.
+ * @auxiliary_virt:          A pointer to a location in the page buffer used
+ *                           for auxiliary bytes. The size of this buffer is
+ *                           determined by struct bch_geometry.
+ * @auxiliary_phys:          The physical address for auxiliary_virt.
+ */
+struct mil {
+	/* MTD Data Structures */
+	struct nand_chip       nand;
+	struct mtd_info        mtd;
+	struct nand_ecclayout  oob_layout;
+
+	/* Partitions*/
+	struct mtd_partition   *partitions;
+	unsigned int           partition_count;
+
+	/* General-use Variables */
+	int                    current_chip;
+	unsigned int           command_length;
+	int                    ignore_bad_block_marks;
+	void                   *saved_bbt;
+
+	/* MTD Function Pointer Hooks */
+	int                    marking_a_bad_block;
+	int                    (*hooked_block_markbad)(struct mtd_info *mtd,
+					loff_t ofs);
+
+	/* from upper layer */
+	uint8_t			*upper_buf;
+	int			upper_len;
+
+	/* DMA */
+	bool			direct_dma_map_ok;
+
+	struct scatterlist	cmd_sgl;
+	char			*cmd_buffer;
+
+	struct scatterlist	data_sgl;
+	char			*data_buffer_dma;
+
+	void                   *page_buffer_virt;
+	dma_addr_t             page_buffer_phys;
+	unsigned int           page_buffer_size;
+
+	void                   *payload_virt;
+	dma_addr_t             payload_phys;
+
+	void                   *auxiliary_virt;
+	dma_addr_t             auxiliary_phys;
+};
+
+/**
+ * struct bch_geometry - NFC geometry description.
+ *
+ * This structure describes the NFC's view of the medium geometry.
+ *
+ * @ecc_algorithm:            The human-readable name of the ECC algorithm
+ *                            (e.g., "Reed-Solomon" or "BCH").
+ * @ecc_strength:             A number that describes the strength of the ECC
+ *                            algorithm.
+ * @page_size_in_bytes:       The size, in bytes, of a physical page, including
+ *                            both data and OOB.
+ * @metadata_size_in_bytes:   The size, in bytes, of the metadata.
+ * @ecc_chunk_size_in_bytes:  The size, in bytes, of a single ECC chunk. Note
+ *                            the first chunk in the page includes both data and
+ *                            metadata, so it's a bit larger than this value.
+ * @ecc_chunk_count:          The number of ECC chunks in the page,
+ * @payload_size_in_bytes:    The size, in bytes, of the payload buffer.
+ * @auxiliary_size_in_bytes:  The size, in bytes, of the auxiliary buffer.
+ * @auxiliary_status_offset:  The offset into the auxiliary buffer at which
+ *                            the ECC status appears.
+ * @block_mark_byte_offset:   The byte offset in the ECC-based page view at
+ *                            which the underlying physical block mark appears.
+ * @block_mark_bit_offset:    The bit offset into the ECC-based page view at
+ *                            which the underlying physical block mark appears.
+ */
+struct bch_geometry {
+	char          *ecc_algorithm;
+	unsigned int  ecc_strength;
+	unsigned int  page_size_in_bytes;
+	unsigned int  metadata_size_in_bytes;
+	unsigned int  ecc_chunk_size_in_bytes;
+	unsigned int  ecc_chunk_count;
+	unsigned int  payload_size_in_bytes;
+	unsigned int  auxiliary_size_in_bytes;
+	unsigned int  auxiliary_status_offset;
+	unsigned int  block_mark_byte_offset;
+	unsigned int  block_mark_bit_offset;
+};
+
+/**
+ * struct boot_rom_geometry - Boot ROM geometry description.
+ *
+ * @stride_size_in_pages:        The size of a boot block stride, in pages.
+ * @search_area_stride_exponent: The logarithm to base 2 of the size of a
+ *                               search area in boot block strides.
+ */
+struct boot_rom_geometry {
+	unsigned int  stride_size_in_pages;
+	unsigned int  search_area_stride_exponent;
+};
+
+/* DMA operations types */
+enum dma_ops_type {
+	DMA_FOR_COMMAND = 1,
+	DMA_FOR_READ_DATA,
+	DMA_FOR_WRITE_DATA,
+	DMA_FOR_READ_ECC_PAGE,
+	DMA_FOR_WRITE_ECC_PAGE
+};
+
+/**
+ * This structure contains the fundamental timing attributes for NAND.
+ *
+ * @data_setup_in_ns:         The data setup time, in nanoseconds. Usually the
+ *                            maximum of tDS and tWP. A negative value
+ *                            indicates this characteristic isn't known.
+ * @data_hold_in_ns:          The data hold time, in nanoseconds. Usually the
+ *                            maximum of tDH, tWH and tREH. A negative value
+ *                            indicates this characteristic isn't known.
+ * @address_setup_in_ns:      The address setup time, in nanoseconds. Usually
+ *                            the maximum of tCLS, tCS and tALS. A negative
+ *                            value indicates this characteristic isn't known.
+ * @gpmi_sample_delay_in_ns:  A GPMI-specific timing parameter. A negative value
+ *                            indicates this characteristic isn't known.
+ * @tREA_in_ns:               tREA, in nanoseconds, from the data sheet. A
+ *                            negative value indicates this characteristic isn't
+ *                            known.
+ * @tRLOH_in_ns:              tRLOH, in nanoseconds, from the data sheet. A
+ *                            negative value indicates this characteristic isn't
+ *                            known.
+ * @tRHOH_in_ns:              tRHOH, in nanoseconds, from the data sheet. A
+ *                            negative value indicates this characteristic isn't
+ *                            known.
+ */
+struct nand_timing {
+	int8_t  data_setup_in_ns;
+	int8_t  data_hold_in_ns;
+	int8_t  address_setup_in_ns;
+	int8_t  gpmi_sample_delay_in_ns;
+	int8_t  tREA_in_ns;
+	int8_t  tRLOH_in_ns;
+	int8_t  tRHOH_in_ns;
+};
+
+struct gpmi_nand_data {
+	/* System Interface */
+	struct device			*dev;
+	struct platform_device		*pdev;
+	struct gpmi_nand_platform_data	*pdata;
+
+	/* Resources */
+	struct resources		resources;
+
+	/* Flash Hardware */
+	struct nand_timing		timing;
+
+	/* BCH */
+	struct bch_geometry		bch_geometry;
+	struct completion		bch_done;
+
+	/* NAND Boot issue */
+	bool				swap_block_mark;
+	struct boot_rom_geometry	rom_geometry;
+
+	/* MTD Interface Layer */
+	struct mil			mil;
+
+	/* DMA channels */
+#define DMA_CHANS			8
+	struct dma_chan			*dma_chans[DMA_CHANS];
+	struct mxs_dma_data		dma_data;
+	enum dma_ops_type		last_dma_type;
+	enum dma_ops_type		dma_type;
+	struct completion		dma_done;
+
+	/* private */
+	void				*private;
+};
+
+/**
+ * struct gpmi_nfc_hardware_timing - GPMI hardware timing parameters.
+ *
+ * This structure contains timing information expressed in a form directly
+ * usable by the GPMI hardware.
+ *
+ * @data_setup_in_cycles:      The data setup time, in cycles.
+ * @data_hold_in_cycles:       The data hold time, in cycles.
+ * @address_setup_in_cycles:   The address setup time, in cycles.
+ * @use_half_periods:          Indicates the clock is running slowly, so the
+ *                             NFC DLL should use half-periods.
+ * @sample_delay_factor:       The sample delay factor.
+ */
+struct gpmi_nfc_hardware_timing {
+	uint8_t  data_setup_in_cycles;
+	uint8_t  data_hold_in_cycles;
+	uint8_t  address_setup_in_cycles;
+	bool     use_half_periods;
+	uint8_t  sample_delay_factor;
+};
+
+/**
+ * struct timing_threshod - timing threshold
+ *
+ * @max_data_setup_cycles:       The maximum number of data setup cycles that
+ *                               can be expressed in the hardware.
+ * @internal_data_setup_in_ns:   The time, in ns, that the NFC hardware requires
+ *                               for data read internal setup. In the Reference
+ *                               Manual, see the chapter "High-Speed NAND
+ *                               Timing" for more details.
+ * @max_sample_delay_factor:     The maximum sample delay factor that can be
+ *                               expressed in the hardware.
+ * @max_dll_clock_period_in_ns:  The maximum period of the GPMI clock that the
+ *                               sample delay DLL hardware can possibly work
+ *                               with (the DLL is unusable with longer periods).
+ *                               If the full-cycle period is greater than HALF
+ *                               this value, the DLL must be configured to use
+ *                               half-periods.
+ * @max_dll_delay_in_ns:         The maximum amount of delay, in ns, that the
+ *                               DLL can implement.
+ * @clock_frequency_in_hz:       The clock frequency, in Hz, during the current
+ *                               I/O transaction. If no I/O transaction is in
+ *                               progress, this is the clock frequency during
+ *                               the most recent I/O transaction.
+ */
+struct timing_threshod {
+	const unsigned int      max_chip_count;
+	const unsigned int      max_data_setup_cycles;
+	const unsigned int      internal_data_setup_in_ns;
+	const unsigned int      max_sample_delay_factor;
+	const unsigned int      max_dll_clock_period_in_ns;
+	const unsigned int      max_dll_delay_in_ns;
+	unsigned long           clock_frequency_in_hz;
+
+};
+
+/* Common Services */
+extern int common_nfc_set_geometry(struct gpmi_nand_data *);
+extern struct dma_chan *get_dma_chan(struct gpmi_nand_data *);
+extern void prepare_data_dma(struct gpmi_nand_data *,
+				enum dma_data_direction dr);
+extern int start_dma_without_bch_irq(struct gpmi_nand_data *,
+				struct dma_async_tx_descriptor *);
+extern int start_dma_with_bch_irq(struct gpmi_nand_data *,
+				struct dma_async_tx_descriptor *);
+
+/* GPMI-NAND helper function library */
+extern int gpmi_init(struct gpmi_nand_data *);
+extern void gpmi_clear_bch(struct gpmi_nand_data *);
+extern void gpmi_show_regs(struct gpmi_nand_data *);
+extern int bch_set_geometry(struct gpmi_nand_data *);
+extern int gpmi_is_ready(struct gpmi_nand_data *, unsigned chip);
+extern int gpmi_send_command(struct gpmi_nand_data *);
+extern void gpmi_begin(struct gpmi_nand_data *);
+extern void gpmi_end(struct gpmi_nand_data *);
+extern int gpmi_read_data(struct gpmi_nand_data *);
+extern int gpmi_send_data(struct gpmi_nand_data *);
+extern int gpmi_send_page(struct gpmi_nand_data *,
+			dma_addr_t payload, dma_addr_t auxiliary);
+extern int gpmi_read_page(struct gpmi_nand_data *,
+			dma_addr_t payload, dma_addr_t auxiliary);
+
+/* ONFI or TOGGLE nand */
+bool is_ddr_nand(struct gpmi_nand_data *);
+
+/* for log */
+extern int gpmi_debug;
+#define GPMI_DEBUG_INIT		0x0001
+#define GPMI_DEBUG_READ		0x0002
+#define GPMI_DEBUG_WRITE	0x0004
+#define GPMI_DEBUG_ECC_READ	0x0008
+#define GPMI_DEBUG_ECC_WRITE	0x0010
+#define GPMI_DEBUG_CRAZY	0x0020
+
+#ifdef pr_fmt
+#undef pr_fmt
+#endif
+
+#define pr_fmt(fmt) "[ %s : %.3d ] " fmt, __func__, __LINE__
+
+#define logio(level)				\
+		do {				\
+			if (gpmi_debug & level)	\
+				pr_info("\n");	\
+		} while (0)
+
+/* BCH : Status Block Completion Codes */
+#define STATUS_GOOD		0x00
+#define STATUS_ERASED		0xff
+#define STATUS_UNCORRECTABLE	0xfe
+
+/* Use the platform_id to distinguish different Archs. */
+#define IS_MX23			0x1
+#define IS_MX28			0x2
+#define GPMI_IS_MX23(x)		((x)->pdev->id_entry->driver_data == IS_MX23)
+#define GPMI_IS_MX28(x)		((x)->pdev->id_entry->driver_data == IS_MX28)
+#endif
-- 
1.7.0.4

[PATCH v8 2/3] MTD : add helper functions library and header files for GPMI NAND driver

[Huang Shijie]

bch-regs.h : registers file for BCH module
gpmi-regs.h: registers file for GPMI module
gpmi-lib.c: helper functions library.

Signed-off-by: Huang Shijie <b32955@freescale.com>
---
 drivers/mtd/nand/gpmi-nand/bch-regs.h  |   88 +++
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |  978 ++++++++++++++++++++++++++++++++
 drivers/mtd/nand/gpmi-nand/gpmi-regs.h |  174 ++++++
 3 files changed, 1240 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mtd/nand/gpmi-nand/bch-regs.h
 create mode 100644 drivers/mtd/nand/gpmi-nand/gpmi-lib.c
 create mode 100644 drivers/mtd/nand/gpmi-nand/gpmi-regs.h

diff --git a/drivers/mtd/nand/gpmi-nand/bch-regs.h b/drivers/mtd/nand/gpmi-nand/bch-regs.h
new file mode 100644
index 0000000..cec1dfa
--- /dev/null
+++ b/drivers/mtd/nand/gpmi-nand/bch-regs.h
@@ -0,0 +1,88 @@
+/*
+ * Freescale GPMI NAND Flash Driver
+ *
+ * Copyright 2008-2011 Freescale Semiconductor, Inc.
+ * Copyright 2008 Embedded Alley Solutions, Inc.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+#ifndef __GPMI_NAND_BCH_REGS_H
+#define __GPMI_NAND_BCH_REGS_H
+
+/*============================================================================*/
+#define HW_BCH_CTRL				0x00000000
+#define HW_BCH_CTRL_SET				0x00000004
+#define HW_BCH_CTRL_CLR				0x00000008
+#define HW_BCH_CTRL_TOG				0x0000000c
+
+#define BM_BCH_CTRL_COMPLETE_IRQ_EN		(1 << 8)
+#define BM_BCH_CTRL_COMPLETE_IRQ		(1 << 0)
+
+/*============================================================================*/
+#define HW_BCH_STATUS0				0x00000010
+#define HW_BCH_MODE				0x00000020
+#define HW_BCH_ENCODEPTR			0x00000030
+#define HW_BCH_DATAPTR				0x00000040
+#define HW_BCH_METAPTR				0x00000050
+#define HW_BCH_LAYOUTSELECT			0x00000070
+
+/*============================================================================*/
+#define HW_BCH_FLASH0LAYOUT0			0x00000080
+
+#define BP_BCH_FLASH0LAYOUT0_NBLOCKS		24
+#define BM_BCH_FLASH0LAYOUT0_NBLOCKS	(0xff << BP_BCH_FLASH0LAYOUT0_NBLOCKS)
+#define BF_BCH_FLASH0LAYOUT0_NBLOCKS(v)		\
+	(((v) << BP_BCH_FLASH0LAYOUT0_NBLOCKS) & BM_BCH_FLASH0LAYOUT0_NBLOCKS)
+
+#define BP_BCH_FLASH0LAYOUT0_META_SIZE		16
+#define BM_BCH_FLASH0LAYOUT0_META_SIZE	(0xff << BP_BCH_FLASH0LAYOUT0_META_SIZE)
+#define BF_BCH_FLASH0LAYOUT0_META_SIZE(v)	\
+	(((v) << BP_BCH_FLASH0LAYOUT0_META_SIZE)\
+					 & BM_BCH_FLASH0LAYOUT0_META_SIZE)
+
+#define BP_BCH_FLASH0LAYOUT0_ECC0		12
+#define BM_BCH_FLASH0LAYOUT0_ECC0	(0xf << BP_BCH_FLASH0LAYOUT0_ECC0)
+#define BF_BCH_FLASH0LAYOUT0_ECC0(v)		\
+	(((v) << BP_BCH_FLASH0LAYOUT0_ECC0) & BM_BCH_FLASH0LAYOUT0_ECC0)
+
+#define BP_BCH_FLASH0LAYOUT0_DATA0_SIZE		0
+#define BM_BCH_FLASH0LAYOUT0_DATA0_SIZE		\
+			(0xfff << BP_BCH_FLASH0LAYOUT0_DATA0_SIZE)
+#define BF_BCH_FLASH0LAYOUT0_DATA0_SIZE(v)	\
+	(((v) << BP_BCH_FLASH0LAYOUT0_DATA0_SIZE)\
+					 & BM_BCH_FLASH0LAYOUT0_DATA0_SIZE)
+
+/*============================================================================*/
+#define HW_BCH_FLASH0LAYOUT1			0x00000090
+
+#define BP_BCH_FLASH0LAYOUT1_PAGE_SIZE		16
+#define BM_BCH_FLASH0LAYOUT1_PAGE_SIZE		\
+			(0xffff << BP_BCH_FLASH0LAYOUT1_PAGE_SIZE)
+#define BF_BCH_FLASH0LAYOUT1_PAGE_SIZE(v)	\
+	(((v) << BP_BCH_FLASH0LAYOUT1_PAGE_SIZE) \
+					 & BM_BCH_FLASH0LAYOUT1_PAGE_SIZE)
+
+#define BP_BCH_FLASH0LAYOUT1_ECCN		12
+#define BM_BCH_FLASH0LAYOUT1_ECCN	(0xf << BP_BCH_FLASH0LAYOUT1_ECCN)
+#define BF_BCH_FLASH0LAYOUT1_ECCN(v)		\
+	(((v) << BP_BCH_FLASH0LAYOUT1_ECCN) & BM_BCH_FLASH0LAYOUT1_ECCN)
+
+#define BP_BCH_FLASH0LAYOUT1_DATAN_SIZE		0
+#define BM_BCH_FLASH0LAYOUT1_DATAN_SIZE		\
+			(0xfff << BP_BCH_FLASH0LAYOUT1_DATAN_SIZE)
+#define BF_BCH_FLASH0LAYOUT1_DATAN_SIZE(v)	\
+	(((v) << BP_BCH_FLASH0LAYOUT1_DATAN_SIZE) \
+					 & BM_BCH_FLASH0LAYOUT1_DATAN_SIZE)
+#endif
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
new file mode 100644
index 0000000..a5cee13
--- /dev/null
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
@@ -0,0 +1,978 @@
+/*
+ * Freescale GPMI NAND Flash Driver
+ *
+ * Copyright (C) 2008-2011 Freescale Semiconductor, Inc.
+ * Copyright (C) 2008 Embedded Alley Solutions, Inc.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+#include "gpmi-nand.h"
+#include "gpmi-regs.h"
+#include "bch-regs.h"
+
+struct timing_threshod timing_default_threshold = {
+	.max_data_setup_cycles       = (BM_GPMI_TIMING0_DATA_SETUP >>
+						BP_GPMI_TIMING0_DATA_SETUP),
+	.internal_data_setup_in_ns   = 0,
+	.max_sample_delay_factor     = (BM_GPMI_CTRL1_RDN_DELAY >>
+						BP_GPMI_CTRL1_RDN_DELAY),
+	.max_dll_clock_period_in_ns  = 32,
+	.max_dll_delay_in_ns         = 16,
+};
+
+int gpmi_init(struct gpmi_nand_data *this)
+{
+	struct resources *r = &this->resources;
+	int ret;
+
+	ret = clk_enable(r->clock);
+	if (ret)
+		goto err_out;
+	ret = mxs_reset_block(r->gpmi_regs);
+	if (ret)
+		goto err_out;
+
+	/* Choose NAND mode. */
+	__raw_writel(BM_GPMI_CTRL1_GPMI_MODE, r->gpmi_regs + HW_GPMI_CTRL1_CLR);
+
+	/* Set the IRQ polarity. */
+	__raw_writel(BM_GPMI_CTRL1_ATA_IRQRDY_POLARITY,
+				r->gpmi_regs + HW_GPMI_CTRL1_SET);
+
+	/* Disable Write-Protection. */
+	__raw_writel(BM_GPMI_CTRL1_DEV_RESET, r->gpmi_regs + HW_GPMI_CTRL1_SET);
+
+	/* Select BCH ECC. */
+	__raw_writel(BM_GPMI_CTRL1_BCH_MODE, r->gpmi_regs + HW_GPMI_CTRL1_SET);
+
+	clk_disable(r->clock);
+	return 0;
+err_out:
+	return ret;
+}
+
+/* This is very useful! */
+void gpmi_show_regs(struct gpmi_nand_data *this)
+{
+	struct resources *r = &this->resources;
+	u32 reg;
+	int i;
+	int n;
+
+	n = HW_GPMI_DEBUG / 0x10 + 1;
+
+	pr_info("-------------- Show GPMI registers ----------\n");
+	for (i = 0; i <= n; i++) {
+		reg = __raw_readl(r->gpmi_regs + i * 0x10);
+		pr_info("offset 0x%.3x : 0x%.8x\n", i * 0x10, reg);
+	}
+	pr_info("-------------- Show GPMI registers end ----------\n");
+}
+
+/* Configures the geometry for BCH.  */
+int bch_set_geometry(struct gpmi_nand_data *this)
+{
+	struct resources *r = &this->resources;
+	struct bch_geometry *bch_geo = &this->bch_geometry;
+	unsigned int block_count;
+	unsigned int block_size;
+	unsigned int metadata_size;
+	unsigned int ecc_strength;
+	unsigned int page_size;
+	int ret;
+
+	if (common_nfc_set_geometry(this))
+		return !0;
+
+	block_count   = bch_geo->ecc_chunk_count - 1;
+	block_size    = bch_geo->ecc_chunk_size_in_bytes;
+	metadata_size = bch_geo->metadata_size_in_bytes;
+	ecc_strength  = bch_geo->ecc_strength >> 1;
+	page_size     = bch_geo->page_size_in_bytes;
+
+	ret = clk_enable(r->clock);
+	if (ret)
+		goto err_out;
+	ret = mxs_reset_block(r->bch_regs);
+	if (ret)
+		goto err_out;
+
+	/* Configure layout 0. */
+	__raw_writel(BF_BCH_FLASH0LAYOUT0_NBLOCKS(block_count)
+			| BF_BCH_FLASH0LAYOUT0_META_SIZE(metadata_size)
+			| BF_BCH_FLASH0LAYOUT0_ECC0(ecc_strength)
+			| BF_BCH_FLASH0LAYOUT0_DATA0_SIZE(block_size),
+			r->bch_regs + HW_BCH_FLASH0LAYOUT0);
+
+	__raw_writel(BF_BCH_FLASH0LAYOUT1_PAGE_SIZE(page_size)
+			| BF_BCH_FLASH0LAYOUT1_ECCN(ecc_strength)
+			| BF_BCH_FLASH0LAYOUT1_DATAN_SIZE(block_size),
+			r->bch_regs + HW_BCH_FLASH0LAYOUT1);
+
+	/* Set *all* chip selects to use layout 0. */
+	__raw_writel(0, r->bch_regs + HW_BCH_LAYOUTSELECT);
+
+	/* Enable interrupts. */
+	__raw_writel(BM_BCH_CTRL_COMPLETE_IRQ_EN,
+				r->bch_regs + HW_BCH_CTRL_SET);
+
+	clk_disable(r->clock);
+	return 0;
+err_out:
+	return ret;
+}
+
+/*
+ * ns_to_cycles - Converts time in nanoseconds to cycles.
+ *
+ * @ntime:   The time, in nanoseconds.
+ * @period:  The cycle period, in nanoseconds.
+ * @min:     The minimum allowable number of cycles.
+ */
+static unsigned int ns_to_cycles(unsigned int time,
+			unsigned int period, unsigned int min)
+{
+	unsigned int k;
+
+	/*
+	 * Compute the minimum number of cycles that entirely contain the
+	 * given time.
+	 */
+	k = (time + period - 1) / period;
+	return max(k, min);
+}
+
+/*
+ * gpmi_compute_hardware_timing - Apply timing to current hardware conditions.
+ *
+ * @this:             Per-device data.
+ * @hardware_timing:  A pointer to a hardware timing structure that will receive
+ *                    the results of our calculations.
+ */
+static int gpmi_nfc_compute_hardware_timing(struct gpmi_nand_data *this,
+					struct gpmi_nfc_hardware_timing *hw)
+{
+	struct gpmi_nand_platform_data *pdata = this->pdata;
+	struct timing_threshod *nfc = &timing_default_threshold;
+	struct nand_chip *nand = &this->mil.nand;
+	struct nand_timing target = this->timing;
+	bool improved_timing_is_available;
+	unsigned long clock_frequency_in_hz;
+	unsigned int clock_period_in_ns;
+	bool dll_use_half_periods;
+	unsigned int dll_delay_shift;
+	unsigned int max_sample_delay_in_ns;
+	unsigned int address_setup_in_cycles;
+	unsigned int data_setup_in_ns;
+	unsigned int data_setup_in_cycles;
+	unsigned int data_hold_in_cycles;
+	int ideal_sample_delay_in_ns;
+	unsigned int sample_delay_factor;
+	int tEYE;
+	unsigned int min_prop_delay_in_ns = pdata->min_prop_delay_in_ns;
+	unsigned int max_prop_delay_in_ns = pdata->max_prop_delay_in_ns;
+
+	/*
+	 * If there are multiple chips, we need to relax the timings to allow
+	 * for signal distortion due to higher capacitance.
+	 */
+	if (nand->numchips > 2) {
+		target.data_setup_in_ns    += 10;
+		target.data_hold_in_ns     += 10;
+		target.address_setup_in_ns += 10;
+	} else if (nand->numchips > 1) {
+		target.data_setup_in_ns    += 5;
+		target.data_hold_in_ns     += 5;
+		target.address_setup_in_ns += 5;
+	}
+
+	/* Check if improved timing information is available. */
+	improved_timing_is_available =
+		(target.tREA_in_ns  >= 0) &&
+		(target.tRLOH_in_ns >= 0) &&
+		(target.tRHOH_in_ns >= 0) ;
+
+	/* Inspect the clock. */
+	clock_frequency_in_hz = nfc->clock_frequency_in_hz;
+	clock_period_in_ns    = 1000000000 / clock_frequency_in_hz;
+
+	/*
+	 * The NFC quantizes setup and hold parameters in terms of clock cycles.
+	 * Here, we quantize the setup and hold timing parameters to the
+	 * next-highest clock period to make sure we apply at least the
+	 * specified times.
+	 *
+	 * For data setup and data hold, the hardware interprets a value of zero
+	 * as the largest possible delay. This is not what's intended by a zero
+	 * in the input parameter, so we impose a minimum of one cycle.
+	 */
+	data_setup_in_cycles    = ns_to_cycles(target.data_setup_in_ns,
+							clock_period_in_ns, 1);
+	data_hold_in_cycles     = ns_to_cycles(target.data_hold_in_ns,
+							clock_period_in_ns, 1);
+	address_setup_in_cycles = ns_to_cycles(target.address_setup_in_ns,
+							clock_period_in_ns, 0);
+
+	/*
+	 * The clock's period affects the sample delay in a number of ways:
+	 *
+	 * (1) The NFC HAL tells us the maximum clock period the sample delay
+	 *     DLL can tolerate. If the clock period is greater than half that
+	 *     maximum, we must configure the DLL to be driven by half periods.
+	 *
+	 * (2) We need to convert from an ideal sample delay, in ns, to a
+	 *     "sample delay factor," which the NFC uses. This factor depends on
+	 *     whether we're driving the DLL with full or half periods.
+	 *     Paraphrasing the reference manual:
+	 *
+	 *         AD = SDF x 0.125 x RP
+	 *
+	 * where:
+	 *
+	 *     AD   is the applied delay, in ns.
+	 *     SDF  is the sample delay factor, which is dimensionless.
+	 *     RP   is the reference period, in ns, which is a full clock period
+	 *          if the DLL is being driven by full periods, or half that if
+	 *          the DLL is being driven by half periods.
+	 *
+	 * Let's re-arrange this in a way that's more useful to us:
+	 *
+	 *                        8
+	 *         SDF  =  AD x ----
+	 *                       RP
+	 *
+	 * The reference period is either the clock period or half that, so this
+	 * is:
+	 *
+	 *                        8       AD x DDF
+	 *         SDF  =  AD x -----  =  --------
+	 *                      f x P        P
+	 *
+	 * where:
+	 *
+	 *       f  is 1 or 1/2, depending on how we're driving the DLL.
+	 *       P  is the clock period.
+	 *     DDF  is the DLL Delay Factor, a dimensionless value that
+	 *          incorporates all the constants in the conversion.
+	 *
+	 * DDF will be either 8 or 16, both of which are powers of two. We can
+	 * reduce the cost of this conversion by using bit shifts instead of
+	 * multiplication or division. Thus:
+	 *
+	 *                 AD << DDS
+	 *         SDF  =  ---------
+	 *                     P
+	 *
+	 *     or
+	 *
+	 *         AD  =  (SDF >> DDS) x P
+	 *
+	 * where:
+	 *
+	 *     DDS  is the DLL Delay Shift, the logarithm to base 2 of the DDF.
+	 */
+	if (clock_period_in_ns > (nfc->max_dll_clock_period_in_ns >> 1)) {
+		dll_use_half_periods = true;
+		dll_delay_shift      = 3 + 1;
+	} else {
+		dll_use_half_periods = false;
+		dll_delay_shift      = 3;
+	}
+
+	/*
+	 * Compute the maximum sample delay the NFC allows, under current
+	 * conditions. If the clock is running too slowly, no sample delay is
+	 * possible.
+	 */
+	if (clock_period_in_ns > nfc->max_dll_clock_period_in_ns)
+		max_sample_delay_in_ns = 0;
+	else {
+		/*
+		 * Compute the delay implied by the largest sample delay factor
+		 * the NFC allows.
+		 */
+		max_sample_delay_in_ns =
+			(nfc->max_sample_delay_factor * clock_period_in_ns) >>
+								dll_delay_shift;
+
+		/*
+		 * Check if the implied sample delay larger than the NFC
+		 * actually allows.
+		 */
+		if (max_sample_delay_in_ns > nfc->max_dll_delay_in_ns)
+			max_sample_delay_in_ns = nfc->max_dll_delay_in_ns;
+	}
+
+	/*
+	 * Check if improved timing information is available. If not, we have to
+	 * use a less-sophisticated algorithm.
+	 */
+	if (!improved_timing_is_available) {
+		/*
+		 * Fold the read setup time required by the NFC into the ideal
+		 * sample delay.
+		 */
+		ideal_sample_delay_in_ns = target.gpmi_sample_delay_in_ns +
+						nfc->internal_data_setup_in_ns;
+
+		/*
+		 * The ideal sample delay may be greater than the maximum
+		 * allowed by the NFC. If so, we can trade off sample delay time
+		 * for more data setup time.
+		 *
+		 * In each iteration of the following loop, we add a cycle to
+		 * the data setup time and subtract a corresponding amount from
+		 * the sample delay until we've satisified the constraints or
+		 * can't do any better.
+		 */
+		while ((ideal_sample_delay_in_ns > max_sample_delay_in_ns) &&
+			(data_setup_in_cycles < nfc->max_data_setup_cycles)) {
+
+			data_setup_in_cycles++;
+			ideal_sample_delay_in_ns -= clock_period_in_ns;
+
+			if (ideal_sample_delay_in_ns < 0)
+				ideal_sample_delay_in_ns = 0;
+
+		}
+
+		/*
+		 * Compute the sample delay factor that corresponds most closely
+		 * to the ideal sample delay. If the result is too large for the
+		 * NFC, use the maximum value.
+		 *
+		 * Notice that we use the ns_to_cycles function to compute the
+		 * sample delay factor. We do this because the form of the
+		 * computation is the same as that for calculating cycles.
+		 */
+		sample_delay_factor =
+			ns_to_cycles(
+				ideal_sample_delay_in_ns << dll_delay_shift,
+							clock_period_in_ns, 0);
+
+		if (sample_delay_factor > nfc->max_sample_delay_factor)
+			sample_delay_factor = nfc->max_sample_delay_factor;
+
+		/* Skip to the part where we return our results. */
+		goto return_results;
+	}
+
+	/*
+	 * If control arrives here, we have more detailed timing information,
+	 * so we can use a better algorithm.
+	 */
+
+	/*
+	 * Fold the read setup time required by the NFC into the maximum
+	 * propagation delay.
+	 */
+	max_prop_delay_in_ns += nfc->internal_data_setup_in_ns;
+
+	/*
+	 * Earlier, we computed the number of clock cycles required to satisfy
+	 * the data setup time. Now, we need to know the actual nanoseconds.
+	 */
+	data_setup_in_ns = clock_period_in_ns * data_setup_in_cycles;
+
+	/*
+	 * Compute tEYE, the width of the data eye when reading from the NAND
+	 * Flash. The eye width is fundamentally determined by the data setup
+	 * time, perturbed by propagation delays and some characteristics of the
+	 * NAND Flash device.
+	 *
+	 * start of the eye = max_prop_delay + tREA
+	 * end of the eye   = min_prop_delay + tRHOH + data_setup
+	 */
+	tEYE = (int)min_prop_delay_in_ns + (int)target.tRHOH_in_ns +
+							(int)data_setup_in_ns;
+
+	tEYE -= (int)max_prop_delay_in_ns + (int)target.tREA_in_ns;
+
+	/*
+	 * The eye must be open. If it's not, we can try to open it by
+	 * increasing its main forcer, the data setup time.
+	 *
+	 * In each iteration of the following loop, we increase the data setup
+	 * time by a single clock cycle. We do this until either the eye is
+	 * open or we run into NFC limits.
+	 */
+	while ((tEYE <= 0) &&
+			(data_setup_in_cycles < nfc->max_data_setup_cycles)) {
+		/* Give a cycle to data setup. */
+		data_setup_in_cycles++;
+		/* Synchronize the data setup time with the cycles. */
+		data_setup_in_ns += clock_period_in_ns;
+		/* Adjust tEYE accordingly. */
+		tEYE += clock_period_in_ns;
+	}
+
+	/*
+	 * When control arrives here, the eye is open. The ideal time to sample
+	 * the data is in the center of the eye:
+	 *
+	 *     end of the eye + start of the eye
+	 *     ---------------------------------  -  data_setup
+	 *                    2
+	 *
+	 * After some algebra, this simplifies to the code immediately below.
+	 */
+	ideal_sample_delay_in_ns =
+		((int)max_prop_delay_in_ns +
+			(int)target.tREA_in_ns +
+				(int)min_prop_delay_in_ns +
+					(int)target.tRHOH_in_ns -
+						(int)data_setup_in_ns) >> 1;
+
+	/*
+	 * The following figure illustrates some aspects of a NAND Flash read:
+	 *
+	 *
+	 *           __                   _____________________________________
+	 * RDN         \_________________/
+	 *
+	 *                                         <---- tEYE ----->
+	 *                                        /-----------------\
+	 * Read Data ----------------------------<                   >---------
+	 *                                        \-----------------/
+	 *             ^                 ^                 ^              ^
+	 *             |                 |                 |              |
+	 *             |<--Data Setup -->|<--Delay Time -->|              |
+	 *             |                 |                 |              |
+	 *             |                 |                                |
+	 *             |                 |<--   Quantized Delay Time   -->|
+	 *             |                 |                                |
+	 *
+	 *
+	 * We have some issues we must now address:
+	 *
+	 * (1) The *ideal* sample delay time must not be negative. If it is, we
+	 *     jam it to zero.
+	 *
+	 * (2) The *ideal* sample delay time must not be greater than that
+	 *     allowed by the NFC. If it is, we can increase the data setup
+	 *     time, which will reduce the delay between the end of the data
+	 *     setup and the center of the eye. It will also make the eye
+	 *     larger, which might help with the next issue...
+	 *
+	 * (3) The *quantized* sample delay time must not fall either before the
+	 *     eye opens or after it closes (the latter is the problem
+	 *     illustrated in the above figure).
+	 */
+
+	/* Jam a negative ideal sample delay to zero. */
+	if (ideal_sample_delay_in_ns < 0)
+		ideal_sample_delay_in_ns = 0;
+
+	/*
+	 * Extend the data setup as needed to reduce the ideal sample delay
+	 * below the maximum permitted by the NFC.
+	 */
+	while ((ideal_sample_delay_in_ns > max_sample_delay_in_ns) &&
+			(data_setup_in_cycles < nfc->max_data_setup_cycles)) {
+
+		/* Give a cycle to data setup. */
+		data_setup_in_cycles++;
+		/* Synchronize the data setup time with the cycles. */
+		data_setup_in_ns += clock_period_in_ns;
+		/* Adjust tEYE accordingly. */
+		tEYE += clock_period_in_ns;
+
+		/*
+		 * Decrease the ideal sample delay by one half cycle, to keep it
+		 * in the middle of the eye.
+		 */
+		ideal_sample_delay_in_ns -= (clock_period_in_ns >> 1);
+
+		/* Jam a negative ideal sample delay to zero. */
+		if (ideal_sample_delay_in_ns < 0)
+			ideal_sample_delay_in_ns = 0;
+	}
+
+	/*
+	 * Compute the sample delay factor that corresponds to the ideal sample
+	 * delay. If the result is too large, then use the maximum allowed
+	 * value.
+	 *
+	 * Notice that we use the ns_to_cycles function to compute the sample
+	 * delay factor. We do this because the form of the computation is the
+	 * same as that for calculating cycles.
+	 */
+	sample_delay_factor =
+		ns_to_cycles(ideal_sample_delay_in_ns << dll_delay_shift,
+							clock_period_in_ns, 0);
+
+	if (sample_delay_factor > nfc->max_sample_delay_factor)
+		sample_delay_factor = nfc->max_sample_delay_factor;
+
+	/*
+	 * These macros conveniently encapsulate a computation we'll use to
+	 * continuously evaluate whether or not the data sample delay is inside
+	 * the eye.
+	 */
+	#define IDEAL_DELAY  ((int) ideal_sample_delay_in_ns)
+
+	#define QUANTIZED_DELAY  \
+		((int) ((sample_delay_factor * clock_period_in_ns) >> \
+							dll_delay_shift))
+
+	#define DELAY_ERROR  (abs(QUANTIZED_DELAY - IDEAL_DELAY))
+
+	#define SAMPLE_IS_NOT_WITHIN_THE_EYE  (DELAY_ERROR > (tEYE >> 1))
+
+	/*
+	 * While the quantized sample time falls outside the eye, reduce the
+	 * sample delay or extend the data setup to move the sampling point back
+	 * toward the eye. Do not allow the number of data setup cycles to
+	 * exceed the maximum allowed by the NFC.
+	 */
+	while (SAMPLE_IS_NOT_WITHIN_THE_EYE &&
+			(data_setup_in_cycles < nfc->max_data_setup_cycles)) {
+		/*
+		 * If control arrives here, the quantized sample delay falls
+		 * outside the eye. Check if it's before the eye opens, or after
+		 * the eye closes.
+		 */
+		if (QUANTIZED_DELAY > IDEAL_DELAY) {
+			/*
+			 * If control arrives here, the quantized sample delay
+			 * falls after the eye closes. Decrease the quantized
+			 * delay time and then go back to re-evaluate.
+			 */
+			if (sample_delay_factor != 0)
+				sample_delay_factor--;
+			continue;
+		}
+
+		/*
+		 * If control arrives here, the quantized sample delay falls
+		 * before the eye opens. Shift the sample point by increasing
+		 * data setup time. This will also make the eye larger.
+		 */
+
+		/* Give a cycle to data setup. */
+		data_setup_in_cycles++;
+		/* Synchronize the data setup time with the cycles. */
+		data_setup_in_ns += clock_period_in_ns;
+		/* Adjust tEYE accordingly. */
+		tEYE += clock_period_in_ns;
+
+		/*
+		 * Decrease the ideal sample delay by one half cycle, to keep it
+		 * in the middle of the eye.
+		 */
+		ideal_sample_delay_in_ns -= (clock_period_in_ns >> 1);
+
+		/* ...and one less period for the delay time. */
+		ideal_sample_delay_in_ns -= clock_period_in_ns;
+
+		/* Jam a negative ideal sample delay to zero. */
+		if (ideal_sample_delay_in_ns < 0)
+			ideal_sample_delay_in_ns = 0;
+
+		/*
+		 * We have a new ideal sample delay, so re-compute the quantized
+		 * delay.
+		 */
+		sample_delay_factor =
+			ns_to_cycles(
+				ideal_sample_delay_in_ns << dll_delay_shift,
+							clock_period_in_ns, 0);
+
+		if (sample_delay_factor > nfc->max_sample_delay_factor)
+			sample_delay_factor = nfc->max_sample_delay_factor;
+	}
+
+	/* Control arrives here when we're ready to return our results. */
+return_results:
+	hw->data_setup_in_cycles    = data_setup_in_cycles;
+	hw->data_hold_in_cycles     = data_hold_in_cycles;
+	hw->address_setup_in_cycles = address_setup_in_cycles;
+	hw->use_half_periods        = dll_use_half_periods;
+	hw->sample_delay_factor     = sample_delay_factor;
+
+	/* Return success. */
+	return 0;
+}
+
+/* Begin the I/O */
+void gpmi_begin(struct gpmi_nand_data *this)
+{
+	struct resources *r = &this->resources;
+	struct timing_threshod *nfc = &timing_default_threshold;
+	unsigned char  *gpmi_regs = r->gpmi_regs;
+	unsigned int   clock_period_in_ns;
+	uint32_t       reg;
+	unsigned int   dll_wait_time_in_us;
+	struct gpmi_nfc_hardware_timing  hw;
+	int ret;
+
+	/* Enable the clock. */
+	ret = clk_enable(r->clock);
+	if (ret) {
+		pr_info("We failed in enable the clk\n");
+		goto err_out;
+	}
+
+	/* set ready/busy timeout */
+	__raw_writel(0x500 << 16, gpmi_regs + HW_GPMI_TIMING1);
+
+	/* Get the timing information we need. */
+	nfc->clock_frequency_in_hz = clk_get_rate(r->clock);
+	clock_period_in_ns = 1000000000 / nfc->clock_frequency_in_hz;
+
+	gpmi_nfc_compute_hardware_timing(this, &hw);
+
+	/* Set up all the simple timing parameters. */
+	reg = BF_GPMI_TIMING0_ADDRESS_SETUP(hw.address_setup_in_cycles) |
+		BF_GPMI_TIMING0_DATA_HOLD(hw.data_hold_in_cycles)         |
+		BF_GPMI_TIMING0_DATA_SETUP(hw.data_setup_in_cycles)       ;
+
+	__raw_writel(reg, gpmi_regs + HW_GPMI_TIMING0);
+
+	/*
+	 * HEY - PAY ATTENTION!
+	 *
+	 * DLL_ENABLE must be set to zero when setting RDN_DELAY or HALF_PERIOD.
+	 */
+	__raw_writel(BM_GPMI_CTRL1_DLL_ENABLE, gpmi_regs + HW_GPMI_CTRL1_CLR);
+
+	/* Clear out the DLL control fields. */
+	__raw_writel(BM_GPMI_CTRL1_RDN_DELAY,   gpmi_regs + HW_GPMI_CTRL1_CLR);
+	__raw_writel(BM_GPMI_CTRL1_HALF_PERIOD, gpmi_regs + HW_GPMI_CTRL1_CLR);
+
+	/* If no sample delay is called for, return immediately. */
+	if (!hw.sample_delay_factor)
+		return;
+
+	/* Configure the HALF_PERIOD flag. */
+	if (hw.use_half_periods)
+		__raw_writel(BM_GPMI_CTRL1_HALF_PERIOD,
+						gpmi_regs + HW_GPMI_CTRL1_SET);
+
+	/* Set the delay factor. */
+	__raw_writel(BF_GPMI_CTRL1_RDN_DELAY(hw.sample_delay_factor),
+						gpmi_regs + HW_GPMI_CTRL1_SET);
+
+	/* Enable the DLL. */
+	__raw_writel(BM_GPMI_CTRL1_DLL_ENABLE, gpmi_regs + HW_GPMI_CTRL1_SET);
+
+	/*
+	 * After we enable the GPMI DLL, we have to wait 64 clock cycles before
+	 * we can use the GPMI.
+	 *
+	 * Calculate the amount of time we need to wait, in microseconds.
+	 */
+	dll_wait_time_in_us = (clock_period_in_ns * 64) / 1000;
+
+	if (!dll_wait_time_in_us)
+		dll_wait_time_in_us = 1;
+
+	/* Wait for the DLL to settle. */
+	udelay(dll_wait_time_in_us);
+
+err_out:
+	return;
+}
+
+void gpmi_end(struct gpmi_nand_data *this)
+{
+	struct resources *r = &this->resources;
+	clk_disable(r->clock);
+}
+
+/* Clears a BCH interrupt. */
+void gpmi_clear_bch(struct gpmi_nand_data *this)
+{
+	struct resources *r = &this->resources;
+	__raw_writel(BM_BCH_CTRL_COMPLETE_IRQ, r->bch_regs + HW_BCH_CTRL_CLR);
+}
+
+/* Returns the Ready/Busy status of the given chip. */
+int gpmi_is_ready(struct gpmi_nand_data *this, unsigned chip)
+{
+	struct resources *r = &this->resources;
+	uint32_t mask;
+	uint32_t reg;
+
+	if (GPMI_IS_MX23(this)) {
+		mask = MX23_BM_GPMI_DEBUG_READY0 << chip;
+		reg = __raw_readl(r->gpmi_regs + HW_GPMI_DEBUG);
+	} else if (GPMI_IS_MX28(this)) {
+		mask = MX28_BF_GPMI_STAT_READY_BUSY(1 << chip);
+		reg = __raw_readl(r->gpmi_regs + HW_GPMI_STAT);
+	} else
+		BUG();
+	return !!(reg & mask);
+}
+
+static inline void set_dma_type(struct gpmi_nand_data *this,
+					enum dma_ops_type type)
+{
+	this->last_dma_type = this->dma_type;
+	this->dma_type = type;
+}
+
+int gpmi_send_command(struct gpmi_nand_data *this)
+{
+	struct dma_chan *channel = get_dma_chan(this);
+	struct mil *mil	= &this->mil;
+	struct dma_async_tx_descriptor *desc;
+	struct scatterlist *sgl;
+	int chip = mil->current_chip;
+	u32 pio[3];
+
+	/* [1] send out the PIO words */
+	pio[0] = BF_GPMI_CTRL0_COMMAND_MODE(BV_GPMI_CTRL0_COMMAND_MODE__WRITE)
+		| BM_GPMI_CTRL0_WORD_LENGTH
+		| BF_GPMI_CTRL0_CS(chip, this)
+		| BF_GPMI_CTRL0_LOCK_CS(LOCK_CS_ENABLE, this)
+		| BF_GPMI_CTRL0_ADDRESS(BV_GPMI_CTRL0_ADDRESS__NAND_CLE)
+		| BM_GPMI_CTRL0_ADDRESS_INCREMENT
+		| BF_GPMI_CTRL0_XFER_COUNT(mil->command_length);
+	pio[1] = pio[2] = 0;
+	desc = channel->device->device_prep_slave_sg(channel,
+					(struct scatterlist *)pio,
+					ARRAY_SIZE(pio), DMA_NONE, 0);
+	if (!desc) {
+		pr_info("step 1 error\n");
+		return -1;
+	}
+
+	/* [2] send out the COMMAND + ADDRESS string stored in @buffer */
+	sgl = &mil->cmd_sgl;
+
+	sg_init_one(sgl, mil->cmd_buffer, mil->command_length);
+	dma_map_sg(this->dev, sgl, 1, DMA_TO_DEVICE);
+	desc = channel->device->device_prep_slave_sg(channel,
+					sgl, 1, DMA_TO_DEVICE, 1);
+	if (!desc) {
+		pr_info("step 2 error\n");
+		return -1;
+	}
+
+	/* [3] submit the DMA */
+	set_dma_type(this, DMA_FOR_COMMAND);
+	return start_dma_without_bch_irq(this, desc);
+}
+
+int gpmi_send_data(struct gpmi_nand_data *this)
+{
+	struct dma_async_tx_descriptor *desc;
+	struct dma_chan *channel = get_dma_chan(this);
+	struct mil *mil	= &this->mil;
+	int chip = mil->current_chip;
+	uint32_t command_mode;
+	uint32_t address;
+	u32 pio[2];
+
+	/* [1] PIO */
+	command_mode = BV_GPMI_CTRL0_COMMAND_MODE__WRITE;
+	address      = BV_GPMI_CTRL0_ADDRESS__NAND_DATA;
+
+	pio[0] = BF_GPMI_CTRL0_COMMAND_MODE(command_mode)
+		| BM_GPMI_CTRL0_WORD_LENGTH
+		| BF_GPMI_CTRL0_CS(chip, this)
+		| BF_GPMI_CTRL0_LOCK_CS(LOCK_CS_ENABLE, this)
+		| BF_GPMI_CTRL0_ADDRESS(address)
+		| BF_GPMI_CTRL0_XFER_COUNT(mil->upper_len);
+	pio[1] = 0;
+	desc = channel->device->device_prep_slave_sg(channel,
+					(struct scatterlist *)pio,
+					ARRAY_SIZE(pio), DMA_NONE, 0);
+	if (!desc) {
+		pr_info("step 1 error\n");
+		return -1;
+	}
+
+	/* [2] send DMA request */
+	prepare_data_dma(this, DMA_TO_DEVICE);
+	desc = channel->device->device_prep_slave_sg(channel, &mil->data_sgl,
+						1, DMA_TO_DEVICE, 1);
+	if (!desc) {
+		pr_info("step 2 error\n");
+		return -1;
+	}
+	/* [3] submit the DMA */
+	set_dma_type(this, DMA_FOR_WRITE_DATA);
+	return start_dma_without_bch_irq(this, desc);
+}
+
+int gpmi_read_data(struct gpmi_nand_data *this)
+{
+	struct dma_async_tx_descriptor *desc;
+	struct dma_chan *channel = get_dma_chan(this);
+	struct mil *mil = &this->mil;
+	int chip = mil->current_chip;
+	u32 pio[2];
+
+	/* [1] : send PIO */
+	pio[0] = BF_GPMI_CTRL0_COMMAND_MODE(BV_GPMI_CTRL0_COMMAND_MODE__READ)
+		| BM_GPMI_CTRL0_WORD_LENGTH
+		| BF_GPMI_CTRL0_CS(chip, this)
+		| BF_GPMI_CTRL0_LOCK_CS(LOCK_CS_ENABLE, this)
+		| BF_GPMI_CTRL0_ADDRESS(BV_GPMI_CTRL0_ADDRESS__NAND_DATA)
+		| BF_GPMI_CTRL0_XFER_COUNT(mil->upper_len);
+	pio[1] = 0;
+	desc = channel->device->device_prep_slave_sg(channel,
+					(struct scatterlist *)pio,
+					ARRAY_SIZE(pio), DMA_NONE, 0);
+	if (!desc) {
+		pr_info("step 1 error\n");
+		return -1;
+	}
+
+	/* [2] : send DMA request */
+	prepare_data_dma(this, DMA_FROM_DEVICE);
+	desc = channel->device->device_prep_slave_sg(channel, &mil->data_sgl,
+						1, DMA_FROM_DEVICE, 1);
+	if (!desc) {
+		pr_info("step 2 error\n");
+		return -1;
+	}
+
+	/* [3] : submit the DMA */
+	set_dma_type(this, DMA_FOR_READ_DATA);
+	return start_dma_without_bch_irq(this, desc);
+}
+
+int gpmi_send_page(struct gpmi_nand_data *this,
+			dma_addr_t payload, dma_addr_t auxiliary)
+{
+	struct bch_geometry *geo = &this->bch_geometry;
+	uint32_t command_mode;
+	uint32_t address;
+	uint32_t ecc_command;
+	uint32_t buffer_mask;
+	struct dma_async_tx_descriptor *desc;
+	struct dma_chan *channel = get_dma_chan(this);
+	struct mil *mil = &this->mil;
+	int chip = mil->current_chip;
+	u32 pio[6];
+
+	/* A DMA descriptor that does an ECC page read. */
+	command_mode = BV_GPMI_CTRL0_COMMAND_MODE__WRITE;
+	address      = BV_GPMI_CTRL0_ADDRESS__NAND_DATA;
+	ecc_command  = BV_GPMI_ECCCTRL_ECC_CMD__BCH_ENCODE;
+	buffer_mask  = BV_GPMI_ECCCTRL_BUFFER_MASK__BCH_PAGE |
+				BV_GPMI_ECCCTRL_BUFFER_MASK__BCH_AUXONLY;
+
+	pio[0] = BF_GPMI_CTRL0_COMMAND_MODE(command_mode)
+		| BM_GPMI_CTRL0_WORD_LENGTH
+		| BF_GPMI_CTRL0_CS(chip, this)
+		| BF_GPMI_CTRL0_LOCK_CS(LOCK_CS_ENABLE, this)
+		| BF_GPMI_CTRL0_ADDRESS(address)
+		| BF_GPMI_CTRL0_XFER_COUNT(0);
+	pio[1] = 0;
+	pio[2] = BM_GPMI_ECCCTRL_ENABLE_ECC
+		| BF_GPMI_ECCCTRL_ECC_CMD(ecc_command)
+		| BF_GPMI_ECCCTRL_BUFFER_MASK(buffer_mask);
+	pio[3] = geo->page_size_in_bytes;
+	pio[4] = payload;
+	pio[5] = auxiliary;
+
+	desc = channel->device->device_prep_slave_sg(channel,
+					(struct scatterlist *)pio,
+					ARRAY_SIZE(pio), DMA_NONE, 0);
+	if (!desc) {
+		pr_info("step 2 error\n");
+		return -1;
+	}
+	set_dma_type(this, DMA_FOR_WRITE_ECC_PAGE);
+	return start_dma_with_bch_irq(this, desc);
+}
+
+int gpmi_read_page(struct gpmi_nand_data *this,
+				dma_addr_t payload, dma_addr_t auxiliary)
+{
+	struct bch_geometry *geo = &this->bch_geometry;
+	uint32_t command_mode;
+	uint32_t address;
+	uint32_t ecc_command;
+	uint32_t buffer_mask;
+	struct dma_async_tx_descriptor *desc;
+	struct dma_chan *channel = get_dma_chan(this);
+	struct mil *mil = &this->mil;
+	int chip = mil->current_chip;
+	u32 pio[6];
+
+	/* [1] Wait for the chip to report ready. */
+	command_mode = BV_GPMI_CTRL0_COMMAND_MODE__WAIT_FOR_READY;
+	address      = BV_GPMI_CTRL0_ADDRESS__NAND_DATA;
+
+	pio[0] =  BF_GPMI_CTRL0_COMMAND_MODE(command_mode)
+		| BM_GPMI_CTRL0_WORD_LENGTH
+		| BF_GPMI_CTRL0_CS(chip, this)
+		| BF_GPMI_CTRL0_LOCK_CS(LOCK_CS_ENABLE, this)
+		| BF_GPMI_CTRL0_ADDRESS(address)
+		| BF_GPMI_CTRL0_XFER_COUNT(0);
+	pio[1] = 0;
+	desc = channel->device->device_prep_slave_sg(channel,
+				(struct scatterlist *)pio, 2, DMA_NONE, 0);
+	if (!desc) {
+		pr_info("step 1 error\n");
+		return -1;
+	}
+
+	/* [2] Enable the BCH block and read. */
+	command_mode = BV_GPMI_CTRL0_COMMAND_MODE__READ;
+	address      = BV_GPMI_CTRL0_ADDRESS__NAND_DATA;
+	ecc_command  = BV_GPMI_ECCCTRL_ECC_CMD__BCH_DECODE;
+	buffer_mask  = BV_GPMI_ECCCTRL_BUFFER_MASK__BCH_PAGE
+			| BV_GPMI_ECCCTRL_BUFFER_MASK__BCH_AUXONLY;
+
+	pio[0] =  BF_GPMI_CTRL0_COMMAND_MODE(command_mode)
+		| BM_GPMI_CTRL0_WORD_LENGTH
+		| BF_GPMI_CTRL0_CS(chip, this)
+		| BF_GPMI_CTRL0_LOCK_CS(LOCK_CS_ENABLE, this)
+		| BF_GPMI_CTRL0_ADDRESS(address)
+		| BF_GPMI_CTRL0_XFER_COUNT(geo->page_size_in_bytes);
+
+	pio[1] = 0;
+	pio[2] =  BM_GPMI_ECCCTRL_ENABLE_ECC
+		| BF_GPMI_ECCCTRL_ECC_CMD(ecc_command)
+		| BF_GPMI_ECCCTRL_BUFFER_MASK(buffer_mask);
+	pio[3] = geo->page_size_in_bytes;
+	pio[4] = payload;
+	pio[5] = auxiliary;
+	desc = channel->device->device_prep_slave_sg(channel,
+					(struct scatterlist *)pio,
+					ARRAY_SIZE(pio), DMA_NONE, 1);
+	if (!desc) {
+		pr_info("step 2 error\n");
+		return -1;
+	}
+
+	/* [3] Disable the BCH block */
+	command_mode = BV_GPMI_CTRL0_COMMAND_MODE__WAIT_FOR_READY;
+	address      = BV_GPMI_CTRL0_ADDRESS__NAND_DATA;
+
+	pio[0] = BF_GPMI_CTRL0_COMMAND_MODE(command_mode)
+		| BM_GPMI_CTRL0_WORD_LENGTH
+		| BF_GPMI_CTRL0_CS(chip, this)
+		| BF_GPMI_CTRL0_LOCK_CS(LOCK_CS_ENABLE, this)
+		| BF_GPMI_CTRL0_ADDRESS(address)
+		| BF_GPMI_CTRL0_XFER_COUNT(geo->page_size_in_bytes);
+	pio[1] = 0;
+	desc = channel->device->device_prep_slave_sg(channel,
+				(struct scatterlist *)pio, 2, DMA_NONE, 1);
+	if (!desc) {
+		pr_info("step 3 error\n");
+		return -1;
+	}
+
+	/* [4] submit the DMA */
+	set_dma_type(this, DMA_FOR_READ_ECC_PAGE);
+	return start_dma_with_bch_irq(this, desc);
+}
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-regs.h b/drivers/mtd/nand/gpmi-nand/gpmi-regs.h
new file mode 100644
index 0000000..c0381cd
--- /dev/null
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-regs.h
@@ -0,0 +1,174 @@
+/*
+ * Freescale GPMI NAND Flash Driver
+ *
+ * Copyright 2008-2011 Freescale Semiconductor, Inc.
+ * Copyright 2008 Embedded Alley Solutions, Inc.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+#ifndef __GPMI_NAND_GPMI_REGS_H
+#define __GPMI_NAND_GPMI_REGS_H
+
+/*============================================================================*/
+#define HW_GPMI_CTRL0					0x00000000
+#define HW_GPMI_CTRL0_SET				0x00000004
+#define HW_GPMI_CTRL0_CLR				0x00000008
+#define HW_GPMI_CTRL0_TOG				0x0000000c
+
+#define BP_GPMI_CTRL0_COMMAND_MODE			24
+#define BM_GPMI_CTRL0_COMMAND_MODE	(3 << BP_GPMI_CTRL0_COMMAND_MODE)
+#define BF_GPMI_CTRL0_COMMAND_MODE(v)	\
+	(((v) << BP_GPMI_CTRL0_COMMAND_MODE) & BM_GPMI_CTRL0_COMMAND_MODE)
+#define BV_GPMI_CTRL0_COMMAND_MODE__WRITE		0x0
+#define BV_GPMI_CTRL0_COMMAND_MODE__READ		0x1
+#define BV_GPMI_CTRL0_COMMAND_MODE__READ_AND_COMPARE	0x2
+#define BV_GPMI_CTRL0_COMMAND_MODE__WAIT_FOR_READY	0x3
+
+#define BM_GPMI_CTRL0_WORD_LENGTH			(1 << 23)
+#define BV_GPMI_CTRL0_WORD_LENGTH__16_BIT		0x0
+#define BV_GPMI_CTRL0_WORD_LENGTH__8_BIT		0x1
+
+/*
+ *  Difference in LOCK_CS between imx23 and imx28 :
+ *  This bit may impact the _POWER_ consumption. So some chips
+ *  do not set it.
+ */
+#define MX23_BP_GPMI_CTRL0_LOCK_CS			22
+#define MX28_BP_GPMI_CTRL0_LOCK_CS			27
+#define LOCK_CS_ENABLE					0x1
+#define BF_GPMI_CTRL0_LOCK_CS(v, x)			0x0
+
+/* Difference in CS between imx23 and imx28 */
+#define BP_GPMI_CTRL0_CS				20
+#define MX23_BM_GPMI_CTRL0_CS		(3 << BP_GPMI_CTRL0_CS)
+#define MX28_BM_GPMI_CTRL0_CS		(7 << BP_GPMI_CTRL0_CS)
+#define BF_GPMI_CTRL0_CS(v, x)		(((v) << BP_GPMI_CTRL0_CS) & \
+						(GPMI_IS_MX23((x)) \
+						? MX23_BM_GPMI_CTRL0_CS	\
+						: MX28_BM_GPMI_CTRL0_CS))
+
+#define BP_GPMI_CTRL0_ADDRESS				17
+#define BM_GPMI_CTRL0_ADDRESS		(3 << BP_GPMI_CTRL0_ADDRESS)
+#define BF_GPMI_CTRL0_ADDRESS(v)	\
+		(((v) << BP_GPMI_CTRL0_ADDRESS) & BM_GPMI_CTRL0_ADDRESS)
+#define BV_GPMI_CTRL0_ADDRESS__NAND_DATA		0x0
+#define BV_GPMI_CTRL0_ADDRESS__NAND_CLE			0x1
+#define BV_GPMI_CTRL0_ADDRESS__NAND_ALE			0x2
+
+#define BM_GPMI_CTRL0_ADDRESS_INCREMENT			(1 << 16)
+#define BV_GPMI_CTRL0_ADDRESS_INCREMENT__DISABLED	0x0
+#define BV_GPMI_CTRL0_ADDRESS_INCREMENT__ENABLED	0x1
+
+#define BP_GPMI_CTRL0_XFER_COUNT			0
+#define BM_GPMI_CTRL0_XFER_COUNT	(0xffff << BP_GPMI_CTRL0_XFER_COUNT)
+#define BF_GPMI_CTRL0_XFER_COUNT(v)	\
+		(((v) << BP_GPMI_CTRL0_XFER_COUNT) & BM_GPMI_CTRL0_XFER_COUNT)
+
+/*============================================================================*/
+#define HW_GPMI_COMPARE					0x00000010
+/*============================================================================*/
+#define HW_GPMI_ECCCTRL					0x00000020
+#define HW_GPMI_ECCCTRL_SET				0x00000024
+#define HW_GPMI_ECCCTRL_CLR				0x00000028
+#define HW_GPMI_ECCCTRL_TOG				0x0000002c
+
+#define BP_GPMI_ECCCTRL_ECC_CMD				13
+#define BM_GPMI_ECCCTRL_ECC_CMD		(3 << BP_GPMI_ECCCTRL_ECC_CMD)
+#define BF_GPMI_ECCCTRL_ECC_CMD(v)	\
+		(((v) << BP_GPMI_ECCCTRL_ECC_CMD) & BM_GPMI_ECCCTRL_ECC_CMD)
+#define BV_GPMI_ECCCTRL_ECC_CMD__BCH_DECODE		0x0
+#define BV_GPMI_ECCCTRL_ECC_CMD__BCH_ENCODE		0x1
+
+#define BM_GPMI_ECCCTRL_ENABLE_ECC			(1 << 12)
+#define BV_GPMI_ECCCTRL_ENABLE_ECC__ENABLE		0x1
+#define BV_GPMI_ECCCTRL_ENABLE_ECC__DISABLE		0x0
+
+#define BP_GPMI_ECCCTRL_BUFFER_MASK			0
+#define BM_GPMI_ECCCTRL_BUFFER_MASK	(0x1ff << BP_GPMI_ECCCTRL_BUFFER_MASK)
+#define BF_GPMI_ECCCTRL_BUFFER_MASK(v)	\
+	(((v) << BP_GPMI_ECCCTRL_BUFFER_MASK) & BM_GPMI_ECCCTRL_BUFFER_MASK)
+#define BV_GPMI_ECCCTRL_BUFFER_MASK__BCH_AUXONLY	0x100
+#define BV_GPMI_ECCCTRL_BUFFER_MASK__BCH_PAGE		0x1FF
+
+/*============================================================================*/
+#define HW_GPMI_ECCCOUNT				0x00000030
+#define HW_GPMI_PAYLOAD					0x00000040
+#define HW_GPMI_AUXILIARY				0x00000050
+/*============================================================================*/
+#define HW_GPMI_CTRL1					0x00000060
+#define HW_GPMI_CTRL1_SET				0x00000064
+#define HW_GPMI_CTRL1_CLR				0x00000068
+#define HW_GPMI_CTRL1_TOG				0x0000006c
+
+#define BM_GPMI_CTRL1_BCH_MODE				(1 << 18)
+
+#define BP_GPMI_CTRL1_DLL_ENABLE			17
+#define BM_GPMI_CTRL1_DLL_ENABLE	(1 << BP_GPMI_CTRL1_DLL_ENABLE)
+
+#define BP_GPMI_CTRL1_HALF_PERIOD			16
+#define BM_GPMI_CTRL1_HALF_PERIOD	(1 << BP_GPMI_CTRL1_HALF_PERIOD)
+
+#define BP_GPMI_CTRL1_RDN_DELAY				12
+#define BM_GPMI_CTRL1_RDN_DELAY		(0xf << BP_GPMI_CTRL1_RDN_DELAY)
+#define BF_GPMI_CTRL1_RDN_DELAY(v)	\
+		(((v) << BP_GPMI_CTRL1_RDN_DELAY) & BM_GPMI_CTRL1_RDN_DELAY)
+
+#define BM_GPMI_CTRL1_DEV_RESET				(1 << 3)
+#define BV_GPMI_CTRL1_DEV_RESET__ENABLED		0x0
+#define BV_GPMI_CTRL1_DEV_RESET__DISABLED		0x1
+
+#define BM_GPMI_CTRL1_ATA_IRQRDY_POLARITY		(1 << 2)
+#define BV_GPMI_CTRL1_ATA_IRQRDY_POLARITY__ACTIVELOW	0x0
+#define BV_GPMI_CTRL1_ATA_IRQRDY_POLARITY__ACTIVEHIGH	0x1
+
+#define BM_GPMI_CTRL1_CAMERA_MODE			(1 << 1)
+#define BV_GPMI_CTRL1_GPMI_MODE__NAND			0x0
+#define BV_GPMI_CTRL1_GPMI_MODE__ATA			0x1
+
+#define BM_GPMI_CTRL1_GPMI_MODE				(1 << 0)
+
+/*============================================================================*/
+#define HW_GPMI_TIMING0					0x00000070
+
+#define BP_GPMI_TIMING0_ADDRESS_SETUP			16
+#define BM_GPMI_TIMING0_ADDRESS_SETUP	(0xff << BP_GPMI_TIMING0_ADDRESS_SETUP)
+#define BF_GPMI_TIMING0_ADDRESS_SETUP(v)	\
+	(((v) << BP_GPMI_TIMING0_ADDRESS_SETUP) & BM_GPMI_TIMING0_ADDRESS_SETUP)
+
+#define BP_GPMI_TIMING0_DATA_HOLD			8
+#define BM_GPMI_TIMING0_DATA_HOLD	(0xff << BP_GPMI_TIMING0_DATA_HOLD)
+#define BF_GPMI_TIMING0_DATA_HOLD(v)		\
+	(((v) << BP_GPMI_TIMING0_DATA_HOLD) & BM_GPMI_TIMING0_DATA_HOLD)
+
+#define BP_GPMI_TIMING0_DATA_SETUP			0
+#define BM_GPMI_TIMING0_DATA_SETUP	(0xff << BP_GPMI_TIMING0_DATA_SETUP)
+#define BF_GPMI_TIMING0_DATA_SETUP(v)		\
+	(((v) << BP_GPMI_TIMING0_DATA_SETUP) & BM_GPMI_TIMING0_DATA_SETUP)
+
+/*============================================================================*/
+#define HW_GPMI_TIMING1					0x00000080
+#define HW_GPMI_TIMING2					0x00000090
+#define HW_GPMI_DATA					0x000000a0
+/*============================ MX28 uses this to detect READY ================*/
+#define HW_GPMI_STAT					0x000000b0
+#define MX28_BP_GPMI_STAT_READY_BUSY			24
+#define MX28_BM_GPMI_STAT_READY_BUSY	(0xff << MX28_BP_GPMI_STAT_READY_BUSY)
+#define MX28_BF_GPMI_STAT_READY_BUSY(v)		\
+	(((v) << MX28_BP_GPMI_STAT_READY_BUSY) & MX28_BM_GPMI_STAT_READY_BUSY)
+/*============================ MX23 uses this to detect READY ================*/
+#define HW_GPMI_DEBUG					0x000000c0
+#define MX23_BP_GPMI_DEBUG_READY0			28
+#define MX23_BM_GPMI_DEBUG_READY0	(1 << MX23_BP_GPMI_DEBUG_READY0)
+#endif
-- 
1.7.0.4

[PATCH v8 3/3] MTD : add GPMI-NAND driver in the config and Makefile

[Huang Shijie]

add the GPMI-NAND driver in the relevant Kconfig and Makefile in the MTD.

Signed-off-by: Huang Shijie <b32955@freescale.com>
---
 drivers/mtd/nand/Kconfig            |   11 +++++++++++
 drivers/mtd/nand/Makefile           |    1 +
 drivers/mtd/nand/gpmi-nand/Makefile |    3 +++
 3 files changed, 15 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mtd/nand/gpmi-nand/Makefile

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 4c34252..97a1350 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -423,6 +423,17 @@ config MTD_NAND_NANDSIM
 	  The simulator may simulate various NAND flash chips for the
 	  MTD nand layer.
 
+config MTD_NAND_GPMI_NAND
+        bool "GPMI NAND Flash Controller driver"
+        depends on MTD_NAND && (SOC_IMX23 || SOC_IMX28)
+	select MTD_PARTITIONS
+	select MTD_CMDLINE_PARTS
+        help
+	 Enables NAND Flash support for IMX23 or IMX28.
+	 The GPMI controller is very powerful, with the help of BCH
+	 module, it can do the hardware ECC. The GPMI supports several
+	 NAND flashs at the same time.
+
 config MTD_NAND_PLATFORM
 	tristate "Support for generic platform NAND driver"
 	help
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 5745d83..b187f82 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -49,5 +49,6 @@ obj-$(CONFIG_MTD_NAND_BCM_UMI)		+= bcm_umi_nand.o nand_bcm_umi.o
 obj-$(CONFIG_MTD_NAND_MPC5121_NFC)	+= mpc5121_nfc.o
 obj-$(CONFIG_MTD_NAND_RICOH)		+= r852.o
 obj-$(CONFIG_MTD_NAND_JZ4740)		+= jz4740_nand.o
+obj-$(CONFIG_MTD_NAND_GPMI_NAND)	+= gpmi-nand/
 
 nand-objs := nand_base.o nand_bbt.o
diff --git a/drivers/mtd/nand/gpmi-nand/Makefile b/drivers/mtd/nand/gpmi-nand/Makefile
new file mode 100644
index 0000000..3a46248
--- /dev/null
+++ b/drivers/mtd/nand/gpmi-nand/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi_nand.o
+gpmi_nand-objs += gpmi-nand.o
+gpmi_nand-objs += gpmi-lib.o
-- 
1.7.0.4

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Wolfram Sang]

> The general-purpose media interface(GPMI) controller is a flexible interface
> to up to several NAND flashs.
...
> To Walfram & Artem:
>     About how to disable the JFFS2 to use the OOB:
>     I read the code, and I still have no idea about how to use the ecclayout
>     to do the job. Could you give me some hint? thanks.

Have you checked mxc_nand.c for example? There is

static struct nand_ecclayout nandv1_hw_eccoob_smallpage = {
        .eccbytes = 5,
        .eccpos = {6, 7, 8, 9, 10},
        .oobfree = {{0, 5}, {12, 4}, }
}

defined as one layout. Now, you could define one where oobfree is empty and
eccbytes as big as the oob-area.

> The driver depends on another GPMI-NAND device patch set, you can find them at :
> 	[1] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037033.html
> 	[2] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037031.html
> 	[3] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037032.html
> 	[4] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037034.html
> 
> The driver also depends on another DMA patch by Shawn:
> 	[0] http://lists.infradead.org/pipermail/linux-mtd/2011-June/036820.html

This makes it difficult for testers/reviewers. Please try to get a git-branch
from Freescale or Linaro.

> 	[4] DMA timeout issue. I use the .config created by `make mxs_defconfig`
> 	    and the bug never occur. It seems some other module has impact to the
> 	    DMA.

Sadly, I can't confirm that. DMA timeout happens with my config as well as with
the mxs_defconfig. ubiformat breaks immediately when trying to write.

Problem is that I am away from my dev-machine for a few days. I can do limited
tests remotely but not develop actively right now. But if you need logs...

Thanks,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110721/77ffac8f/attachment-0001.sig>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Huang Shijie]

Hi,
>> The general-purpose media interface(GPMI) controller is a flexible interface
>> to up to several NAND flashs.
> ...
>> To Walfram & Artem:
>>     About how to disable the JFFS2 to use the OOB:
>>     I read the code, and I still have no idea about how to use the ecclayout
>>     to do the job. Could you give me some hint? thanks.
> Have you checked mxc_nand.c for example? There is
>
> static struct nand_ecclayout nandv1_hw_eccoob_smallpage = {
>         .eccbytes = 5,
>         .eccpos = {6, 7, 8, 9, 10},
>         .oobfree = {{0, 5}, {12, 4}, }
> }
>
> defined as one layout. Now, you could define one where oobfree is empty and
> eccbytes as big as the oob-area.
>
thanks. I will check the code.
>> The driver depends on another GPMI-NAND device patch set, you can find them at :
>> 	[1] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037033.html
>> 	[2] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037031.html
>> 	[3] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037032.html
>> 	[4] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037034.html
>>
>> The driver also depends on another DMA patch by Shawn:
>> 	[0] http://lists.infradead.org/pipermail/linux-mtd/2011-June/036820.html
> This makes it difficult for testers/reviewers. Please try to get a git-branch
> from Freescale or Linaro.
>
Shawn will merge my patches to his Linaro branch.

>> 	[4] DMA timeout issue. I use the .config created by `make mxs_defconfig`
>> 	    and the bug never occur. It seems some other module has impact to the
>> 	    DMA.
> Sadly, I can't confirm that. DMA timeout happens with my config as well as with
> the mxs_defconfig. ubiformat breaks immediately when trying to write.
Please check the attachment:
[1] my_config is my tested .config file, you can test it.
[2] a.sh is my testing shell script which also tests the ubiformat.

Best Regards
Huang Shijie


> Problem is that I am away from my dev-machine for a few days. I can do limited
> tests remotely but not develop actively right now. But if you need logs...
>
> Thanks,
>
>    Wolfram
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: my_config
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110722/0317e8b2/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.sh
Type: application/x-sh
Size: 347 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110722/0317e8b2/attachment-0001.sh>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Shawn Guo]

On Fri, Jul 22, 2011 at 11:30:41AM +0800, Huang Shijie wrote:
> Hi,
> >> The general-purpose media interface(GPMI) controller is a flexible interface
> >> to up to several NAND flashs.
> > ...
> >> To Walfram & Artem:
> >>     About how to disable the JFFS2 to use the OOB:
> >>     I read the code, and I still have no idea about how to use the ecclayout
> >>     to do the job. Could you give me some hint? thanks.
> > Have you checked mxc_nand.c for example? There is
> >
> > static struct nand_ecclayout nandv1_hw_eccoob_smallpage = {
> >         .eccbytes = 5,
> >         .eccpos = {6, 7, 8, 9, 10},
> >         .oobfree = {{0, 5}, {12, 4}, }
> > }
> >
> > defined as one layout. Now, you could define one where oobfree is empty and
> > eccbytes as big as the oob-area.
> >
> thanks. I will check the code.
> >> The driver depends on another GPMI-NAND device patch set, you can find them at :
> >> 	[1] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037033.html
> >> 	[2] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037031.html
> >> 	[3] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037032.html
> >> 	[4] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037034.html
> >>
> >> The driver also depends on another DMA patch by Shawn:
> >> 	[0] http://lists.infradead.org/pipermail/linux-mtd/2011-June/036820.html
> > This makes it difficult for testers/reviewers. Please try to get a git-branch
> > from Freescale or Linaro.
> >
> Shawn will merge my patches to his Linaro branch.
> 

git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi

Shijie, please check and test it.  I only did a build test.

-- 
Regards,
Shawn

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Huang Shijie]

Hi Wolfram:
> On Fri, Jul 22, 2011 at 11:30:41AM +0800, Huang Shijie wrote:
>> Hi,
>>>> The general-purpose media interface(GPMI) controller is a flexible interface
>>>> to up to several NAND flashs.
>>> ...
>>>> To Walfram&  Artem:
>>>>      About how to disable the JFFS2 to use the OOB:
>>>>      I read the code, and I still have no idea about how to use the ecclayout
>>>>      to do the job. Could you give me some hint? thanks.
>>> Have you checked mxc_nand.c for example? There is
>>>
>>> static struct nand_ecclayout nandv1_hw_eccoob_smallpage = {
>>>          .eccbytes = 5,
>>>          .eccpos = {6, 7, 8, 9, 10},
>>>          .oobfree = {{0, 5}, {12, 4}, }
>>> }
>>>
>>> defined as one layout. Now, you could define one where oobfree is empty and
>>> eccbytes as big as the oob-area.
>>>
>> thanks. I will check the code.
>>>> The driver depends on another GPMI-NAND device patch set, you can find them at :
>>>> 	[1] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037033.html
>>>> 	[2] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037031.html
>>>> 	[3] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037032.html
>>>> 	[4] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037034.html
>>>>
>>>> The driver also depends on another DMA patch by Shawn:
>>>> 	[0] http://lists.infradead.org/pipermail/linux-mtd/2011-June/036820.html
>>> This makes it difficult for testers/reviewers. Please try to get a git-branch
>>> from Freescale or Linaro.
>>>
>> Shawn will merge my patches to his Linaro branch.
>>
> git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi
Please test the GPMI driver based this git tree.

I tested, and the DMA-timeout does not occur any more.

I notice that Shawn added two more patched to 
/arch/arm/config/mxs_defconfig:
[1] ARM: mxs_defconfig: Add mx23evk and mx28evk build
[2] ARM: mxs_defconfig: Change CONFIG_RTC_CLASS 'm' to 'y'

Please check it. Maybe your kernel code misses them.

Of course, you can use the my_config (i sent you last mail) for .config.

Best Regards
Huang Shijie


> Shijie, please check and test it.  I only did a build test.
>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Koen Beel]

Hi,

It's not really working for me.
I've applied all gpmi-nand driver patches and the dma driver patches.

I have added following kernel parameters:
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
rootfstype=ubifs gpmi_debug_init

During boot I get already get DMA timeout:
[    2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA :1
[    3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
...
(see log file in attach line 89)

When trying flash_erraseall /dev/mtd1 I get:
Erasing 128 Kibyte @ 20000 --  0 % complete [   16.700000] [
gpmi_read_data : 832 ] step 1 error
[   16.700000] [ gpmi_send_command : 749 ] step 1 error
[   16.700000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
[   16.700000] [ gpmi_send_command : 749 ] step 1 error
[   16.700000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
[   16.700000] [ gpmi_send_command : 749 ] step 1 error
[   16.700000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
[   16.700000] [ gpmi_read_data : 832 ] step 1 error
libmtd: error!: MEMERA[   16.740000] [ gpmi_send_command : 749 ] step 1 error
SE64 ioctl failed for eraseblock[   16.750000] [ mil_cmd_ctrl : 894 ]
Chip: 0, Error -1
 1 (mtd1)
        error 5 (Input/output error)
flash_erase: error!: /dev/mtd1: MTD Erase failure
             error 5 (Input/output error)
...
(see log file in attach line 128 and further)

Environment:
- patches on a 2.6.39.1 kernel (needed to modify the patch a little
for changed mtd add/del interface).
- using this on our own mx23 based board, so also added some board
init code for that.


On Fri, Jul 22, 2011 at 10:07 AM, Huang Shijie <b32955@freescale.com> wrote:
> Hi Wolfram:
>>
>> On Fri, Jul 22, 2011 at 11:30:41AM +0800, Huang Shijie wrote:
>>>
>>> Hi,
>>>>>
>>>>> The general-purpose media interface(GPMI) controller is a flexible
>>>>> interface
>>>>> to up to several NAND flashs.
>>>>
>>>> ...
>>>>>
>>>>> To Walfram& ?Artem:
>>>>> ? ? About how to disable the JFFS2 to use the OOB:
>>>>> ? ? I read the code, and I still have no idea about how to use the
>>>>> ecclayout
>>>>> ? ? to do the job. Could you give me some hint? thanks.
>>>>
>>>> Have you checked mxc_nand.c for example? There is
>>>>
>>>> static struct nand_ecclayout nandv1_hw_eccoob_smallpage = {
>>>> ? ? ? ? .eccbytes = 5,
>>>> ? ? ? ? .eccpos = {6, 7, 8, 9, 10},
>>>> ? ? ? ? .oobfree = {{0, 5}, {12, 4}, }
>>>> }
>>>>
>>>> defined as one layout. Now, you could define one where oobfree is empty
>>>> and
>>>> eccbytes as big as the oob-area.
>>>>
>>> thanks. I will check the code.
>>>>>
>>>>> The driver depends on another GPMI-NAND device patch set, you can find
>>>>> them at :
>>>>> ? ? ? ?[1]
>>>>> http://lists.infradead.org/pipermail/linux-mtd/2011-July/037033.html
>>>>> ? ? ? ?[2]
>>>>> http://lists.infradead.org/pipermail/linux-mtd/2011-July/037031.html
>>>>> ? ? ? ?[3]
>>>>> http://lists.infradead.org/pipermail/linux-mtd/2011-July/037032.html
>>>>> ? ? ? ?[4]
>>>>> http://lists.infradead.org/pipermail/linux-mtd/2011-July/037034.html
>>>>>
>>>>> The driver also depends on another DMA patch by Shawn:
>>>>> ? ? ? ?[0]
>>>>> http://lists.infradead.org/pipermail/linux-mtd/2011-June/036820.html
>>>>
>>>> This makes it difficult for testers/reviewers. Please try to get a
>>>> git-branch
>>>> from Freescale or Linaro.
>>>>
>>> Shawn will merge my patches to his Linaro branch.

I don't see the DMA patch in the git?

>>>
>> git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi
>
> Please test the GPMI driver based this git tree.

I will try that on an mx23evk board.

>
> I tested, and the DMA-timeout does not occur any more.
>
> I notice that Shawn added two more patched to
> /arch/arm/config/mxs_defconfig:
> [1] ARM: mxs_defconfig: Add mx23evk and mx28evk build
> [2] ARM: mxs_defconfig: Change CONFIG_RTC_CLASS 'm' to 'y'
>
> Please check it. Maybe your kernel code misses them.

I don't see any of this in the git?

>
> Of course, you can use the my_config (i sent you last mail) for .config.
>
> Best Regards
> Huang Shijie
>
>
>> Shijie, please check and test it. ?I only did a build test.
>>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Huang Shijie]

Hi,

Thanks for your test.

> Hi,
>
> It's not really working for me.
> I've applied all gpmi-nand driver patches and the dma driver patches.
>
> I have added following kernel parameters:
> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
> rootfstype=ubifs gpmi_debug_init
>
> During boot I get already get DMA timeout:
> [    2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA :1
> [    3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
> ...
> (see log file in attach line 89)
>
> When trying flash_erraseall /dev/mtd1 I get:
> Erasing 128 Kibyte @ 20000 --  0 % complete [   16.700000] [
> gpmi_read_data : 832 ] step 1 error
> [   16.700000] [ gpmi_send_command : 749 ] step 1 error
> [   16.700000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
> [   16.700000] [ gpmi_send_command : 749 ] step 1 error
> [   16.700000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
> [   16.700000] [ gpmi_send_command : 749 ] step 1 error
> [   16.700000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
> [   16.700000] [ gpmi_read_data : 832 ] step 1 error
> libmtd: error!: MEMERA[   16.740000] [ gpmi_send_command : 749 ] step 1 error
> SE64 ioctl failed for eraseblock[   16.750000] [ mil_cmd_ctrl : 894 ]
> Chip: 0, Error -1
>   1 (mtd1)
>          error 5 (Input/output error)
> flash_erase: error!: /dev/mtd1: MTD Erase failure
>               error 5 (Input/output error)
> ...
> (see log file in attach line 128 and further)
>
> Environment:
> - patches on a 2.6.39.1 kernel (needed to modify the patch a little
> for changed mtd add/del interface).
Please test the driver on :
   git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi

or on

  git://git.pengutronix.de/git/imx/linux-2.6.git  imx-for-3.1



I found the .config may influence the DMA.
I guess there is some module which has impact to the DMA.
So You should use the right .config first, you can get the right
.config by two ways:
[1] use the 'make mxs_defconfig' in the imx-for-3.1 branch of
   tree: git://git.pengutronix.de/git/imx/linux-2.6.git

[2] use the attachment which is tested by me.

Best Regards
Huang Shijie



> - using this on our own mx23 based board, so also added some board
> init code for that.
>
>
> On Fri, Jul 22, 2011 at 10:07 AM, Huang Shijie<b32955@freescale.com>  wrote:
>> Hi Wolfram:
>>> On Fri, Jul 22, 2011 at 11:30:41AM +0800, Huang Shijie wrote:
>>>> Hi,
>>>>>> The general-purpose media interface(GPMI) controller is a flexible
>>>>>> interface
>>>>>> to up to several NAND flashs.
>>>>> ...
>>>>>> To Walfram&    Artem:
>>>>>>      About how to disable the JFFS2 to use the OOB:
>>>>>>      I read the code, and I still have no idea about how to use the
>>>>>> ecclayout
>>>>>>      to do the job. Could you give me some hint? thanks.
>>>>> Have you checked mxc_nand.c for example? There is
>>>>>
>>>>> static struct nand_ecclayout nandv1_hw_eccoob_smallpage = {
>>>>>          .eccbytes = 5,
>>>>>          .eccpos = {6, 7, 8, 9, 10},
>>>>>          .oobfree = {{0, 5}, {12, 4}, }
>>>>> }
>>>>>
>>>>> defined as one layout. Now, you could define one where oobfree is empty
>>>>> and
>>>>> eccbytes as big as the oob-area.
>>>>>
>>>> thanks. I will check the code.
>>>>>> The driver depends on another GPMI-NAND device patch set, you can find
>>>>>> them at :
>>>>>>         [1]
>>>>>> http://lists.infradead.org/pipermail/linux-mtd/2011-July/037033.html
>>>>>>         [2]
>>>>>> http://lists.infradead.org/pipermail/linux-mtd/2011-July/037031.html
>>>>>>         [3]
>>>>>> http://lists.infradead.org/pipermail/linux-mtd/2011-July/037032.html
>>>>>>         [4]
>>>>>> http://lists.infradead.org/pipermail/linux-mtd/2011-July/037034.html
>>>>>>
>>>>>> The driver also depends on another DMA patch by Shawn:
>>>>>>         [0]
>>>>>> http://lists.infradead.org/pipermail/linux-mtd/2011-June/036820.html
>>>>> This makes it difficult for testers/reviewers. Please try to get a
>>>>> git-branch
>>>>> from Freescale or Linaro.
>>>>>
>>>> Shawn will merge my patches to his Linaro branch.
> I don't see the DMA patch in the git?
>
>>> git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi
>> Please test the GPMI driver based this git tree.
> I will try that on an mx23evk board.
>
>> I tested, and the DMA-timeout does not occur any more.
>>
>> I notice that Shawn added two more patched to
>> /arch/arm/config/mxs_defconfig:
>> [1] ARM: mxs_defconfig: Add mx23evk and mx28evk build
>> [2] ARM: mxs_defconfig: Change CONFIG_RTC_CLASS 'm' to 'y'
>>
>> Please check it. Maybe your kernel code misses them.
> I don't see any of this in the git?
>
>> Of course, you can use the my_config (i sent you last mail) for .config.
>>
>> Best Regards
>> Huang Shijie
>>
>>
>>> Shijie, please check and test it.  I only did a build test.
>>>
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: my_config
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110727/ac087c9b/attachment-0001.ksh>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Koen Beel]

Hi,

I have test on mx23evk board. Still see the same issues.

On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie <b32955@freescale.com> wrote:
> Hi,
>
> Thanks for your test.
>
>> Hi,
>>
>> It's not really working for me.
>> I've applied all gpmi-nand driver patches and the dma driver patches.
>>
>> I have added following kernel parameters:
>> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
>> rootfstype=ubifs gpmi_debug_init
>>
>> During boot I get already get DMA timeout:
>> [ ? ?2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA
>> :1
>> [ ? ?3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
>> ...
>> (see log file in attach line 89)

I still see this DMA timeout when booting.
What kernel parameters do you use? I still use same as above.

>>
>> When trying flash_erraseall /dev/mtd1 I get:
>> Erasing 128 Kibyte @ 20000 -- ?0 % complete [ ? 16.700000] [
>> gpmi_read_data : 832 ] step 1 error
>> [ ? 16.700000] [ gpmi_send_command : 749 ] step 1 error
>> [ ? 16.700000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
>> [ ? 16.700000] [ gpmi_send_command : 749 ] step 1 error
>> [ ? 16.700000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
>> [ ? 16.700000] [ gpmi_send_command : 749 ] step 1 error
>> [ ? 16.700000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
>> [ ? 16.700000] [ gpmi_read_data : 832 ] step 1 error
>> libmtd: error!: MEMERA[ ? 16.740000] [ gpmi_send_command : 749 ] step 1
>> error
>> SE64 ioctl failed for eraseblock[ ? 16.750000] [ mil_cmd_ctrl : 894 ]
>> Chip: 0, Error -1
>> ?1 (mtd1)
>> ? ? ? ? error 5 (Input/output error)
>> flash_erase: error!: /dev/mtd1: MTD Erase failure
>> ? ? ? ? ? ? ?error 5 (Input/output error)
>> ...
>> (see log file in attach line 128 and further)

Also still same issue here.

>>
>> Environment:
>> - patches on a 2.6.39.1 kernel (needed to modify the patch a little
>> for changed mtd add/del interface).
>
> Please test the driver on :
> ?git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi

I have used this branch.

>
> or on
>
> ?git://git.pengutronix.de/git/imx/linux-2.6.git ?imx-for-3.1
>
>
>
> I found the .config may influence the DMA.
> I guess there is some module which has impact to the DMA.
> So You should use the right .config first, you can get the right
> .config by two ways:
> [1] use the 'make mxs_defconfig' in the imx-for-3.1 branch of
> ?tree: git://git.pengutronix.de/git/imx/linux-2.6.git
>
> [2] use the attachment which is tested by me.

I have used this config file. Only thing changed to the config file is
(uboot savenv not working):
CONFIG_CMDLINE="console=ttyAMA0,115200
mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
rootfstype=ubifs gpmi_debug_init"
CONFIG_CMDLINE_FORCE=y


br,
Koen

>
> Best Regards
> Huang Shijie
>
>
>
>> - using this on our own mx23 based board, so also added some board
>> init code for that.
>>
>>
>> On Fri, Jul 22, 2011 at 10:07 AM, Huang Shijie<b32955@freescale.com>
>> ?wrote:
>>>
>>> Hi Wolfram:
>>>>
>>>> On Fri, Jul 22, 2011 at 11:30:41AM +0800, Huang Shijie wrote:
>>>>>
>>>>> Hi,
>>>>>>>
>>>>>>> The general-purpose media interface(GPMI) controller is a flexible
>>>>>>> interface
>>>>>>> to up to several NAND flashs.
>>>>>>
>>>>>> ...
>>>>>>>
>>>>>>> To Walfram& ? ?Artem:
>>>>>>> ? ? About how to disable the JFFS2 to use the OOB:
>>>>>>> ? ? I read the code, and I still have no idea about how to use the
>>>>>>> ecclayout
>>>>>>> ? ? to do the job. Could you give me some hint? thanks.
>>>>>>
>>>>>> Have you checked mxc_nand.c for example? There is
>>>>>>
>>>>>> static struct nand_ecclayout nandv1_hw_eccoob_smallpage = {
>>>>>> ? ? ? ? .eccbytes = 5,
>>>>>> ? ? ? ? .eccpos = {6, 7, 8, 9, 10},
>>>>>> ? ? ? ? .oobfree = {{0, 5}, {12, 4}, }
>>>>>> }
>>>>>>
>>>>>> defined as one layout. Now, you could define one where oobfree is
>>>>>> empty
>>>>>> and
>>>>>> eccbytes as big as the oob-area.
>>>>>>
>>>>> thanks. I will check the code.
>>>>>>>
>>>>>>> The driver depends on another GPMI-NAND device patch set, you can
>>>>>>> find
>>>>>>> them at :
>>>>>>> ? ? ? ?[1]
>>>>>>> http://lists.infradead.org/pipermail/linux-mtd/2011-July/037033.html
>>>>>>> ? ? ? ?[2]
>>>>>>> http://lists.infradead.org/pipermail/linux-mtd/2011-July/037031.html
>>>>>>> ? ? ? ?[3]
>>>>>>> http://lists.infradead.org/pipermail/linux-mtd/2011-July/037032.html
>>>>>>> ? ? ? ?[4]
>>>>>>> http://lists.infradead.org/pipermail/linux-mtd/2011-July/037034.html
>>>>>>>
>>>>>>> The driver also depends on another DMA patch by Shawn:
>>>>>>> ? ? ? ?[0]
>>>>>>> http://lists.infradead.org/pipermail/linux-mtd/2011-June/036820.html
>>>>>>
>>>>>> This makes it difficult for testers/reviewers. Please try to get a
>>>>>> git-branch
>>>>>> from Freescale or Linaro.
>>>>>>
>>>>> Shawn will merge my patches to his Linaro branch.
>>
>> I don't see the DMA patch in the git?
>>
>>>> git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi
>>>
>>> Please test the GPMI driver based this git tree.
>>
>> I will try that on an mx23evk board.
>>
>>> I tested, and the DMA-timeout does not occur any more.
>>>
>>> I notice that Shawn added two more patched to
>>> /arch/arm/config/mxs_defconfig:
>>> [1] ARM: mxs_defconfig: Add mx23evk and mx28evk build
>>> [2] ARM: mxs_defconfig: Change CONFIG_RTC_CLASS 'm' to 'y'
>>>
>>> Please check it. Maybe your kernel code misses them.
>>
>> I don't see any of this in the git?
>>
>>> Of course, you can use the my_config (i sent you last mail) for .config.
>>>
>>> Best Regards
>>> Huang Shijie
>>>
>>>
>>>> Shijie, please check and test it. ?I only did a build test.
>>>>
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>
>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Lothar Waßmann]

Hi,

Koen Beel writes:
> Hi,
> 
> I have test on mx23evk board. Still see the same issues.
> 
> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie <b32955@freescale.com> wrote:
> > Hi,
> >
> > Thanks for your test.
> >
> >> Hi,
> >>
> >> It's not really working for me.
> >> I've applied all gpmi-nand driver patches and the dma driver patches.
> >>
> >> I have added following kernel parameters:
> >> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
> >> rootfstype=ubifs gpmi_debug_init
> >>
> >> During boot I get already get DMA timeout:
> >> [ ? ?2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA
> >> :1
> >> [ ? ?3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
> >> ...
> >> (see log file in attach line 89)
> 
> I still see this DMA timeout when booting.
> What kernel parameters do you use? I still use same as above.
> 
Do you have an SD card in the system? I'm getting the same error when
accessing an SD card. Without SD card I can use the flash without any
errors.


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Koen Beel]

Hi,

On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann <LW@karo-electronics.de> wrote:
> Hi,
>
> Koen Beel writes:
>> Hi,
>>
>> I have test on mx23evk board. Still see the same issues.
>>
>> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie <b32955@freescale.com> wrote:
>> > Hi,
>> >
>> > Thanks for your test.
>> >
>> >> Hi,
>> >>
>> >> It's not really working for me.
>> >> I've applied all gpmi-nand driver patches and the dma driver patches.
>> >>
>> >> I have added following kernel parameters:
>> >> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
>> >> rootfstype=ubifs gpmi_debug_init
>> >>
>> >> During boot I get already get DMA timeout:
>> >> [ ? ?2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA
>> >> :1
>> >> [ ? ?3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
>> >> ...
>> >> (see log file in attach line 89)
>>
>> I still see this DMA timeout when booting.
>> What kernel parameters do you use? I still use same as above.
>>
> Do you have an SD card in the system? I'm getting the same error when
> accessing an SD card. Without SD card I can use the flash without any
> errors.

No SD card in the system. At least not on my mx23evk board.
My real target hardware has a SDIO wifi chip.

Are you also testing on the mx23evk board? Really strange it is not
reproducible here then.
Anyone using mx23evk please give:
- revision number of board (I have tested on rev C1)
- kernel parameter used (see previous mail for mine)

Regards,
Koen

>
>
> Lothar Wa?mann
> --
> ___________________________________________________________
>
> Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
> Gesch?ftsf?hrer: Matthias Kaussen
> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>
> www.karo-electronics.de | info at karo-electronics.de
> ___________________________________________________________
>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Lothar Waßmann]

Hi,

Koen Beel writes:
> Hi,
> 
> On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann <LW@karo-electronics.de> wrote:
> > Hi,
> >
> > Koen Beel writes:
> >> Hi,
> >>
> >> I have test on mx23evk board. Still see the same issues.
> >>
> >> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie <b32955@freescale.com> wrote:
> >> > Hi,
> >> >
> >> > Thanks for your test.
> >> >
> >> >> Hi,
> >> >>
> >> >> It's not really working for me.
> >> >> I've applied all gpmi-nand driver patches and the dma driver patches.
> >> >>
> >> >> I have added following kernel parameters:
> >> >> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
> >> >> rootfstype=ubifs gpmi_debug_init
> >> >>
> >> >> During boot I get already get DMA timeout:
> >> >> [ ? ?2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA
> >> >> :1
> >> >> [ ? ?3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
> >> >> ...
> >> >> (see log file in attach line 89)
> >>
> >> I still see this DMA timeout when booting.
> >> What kernel parameters do you use? I still use same as above.
> >>
> > Do you have an SD card in the system? I'm getting the same error when
> > accessing an SD card. Without SD card I can use the flash without any
> > errors.
> 
> No SD card in the system. At least not on my mx23evk board.
> My real target hardware has a SDIO wifi chip.
> 
> Are you also testing on the mx23evk board? Really strange it is not
> reproducible here then.
>
No, I'm working on a TX28.


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Huang Shijie]

? 2011?07?29? 15:40, Koen Beel ??:
> Hi,
>
> On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann<LW@karo-electronics.de>  wrote:
>> Hi,
>>
>> Koen Beel writes:
>>> Hi,
>>>
>>> I have test on mx23evk board. Still see the same issues.
>>>
>>> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<b32955@freescale.com>  wrote:
>>>> Hi,
>>>>
>>>> Thanks for your test.
>>>>
>>>>> Hi,
>>>>>
>>>>> It's not really working for me.
>>>>> I've applied all gpmi-nand driver patches and the dma driver patches.
>>>>>
>>>>> I have added following kernel parameters:
>>>>> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
>>>>> rootfstype=ubifs gpmi_debug_init
>>>>>
>>>>> During boot I get already get DMA timeout:
>>>>> [    2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA
>>>>> :1
>>>>> [    3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
>>>>> ...
>>>>> (see log file in attach line 89)
>>> I still see this DMA timeout when booting.
>>> What kernel parameters do you use? I still use same as above.
>>>
>> Do you have an SD card in the system? I'm getting the same error when
>> accessing an SD card. Without SD card I can use the flash without any
>> errors.
> No SD card in the system. At least not on my mx23evk board.
> My real target hardware has a SDIO wifi chip.
Does it conflict with the GPMI?
> Are you also testing on the mx23evk board? Really strange it is not
> reproducible here then.
> Anyone using mx23evk please give:
I tested the code in mx23evk.
After boot the kernel and login the shell, I met a problem:
  the flash_eraseall can not run with the log:
"Floating point exception"
:(


> - revision number of board (I have tested on rev C1)
Revision number is C.
> - kernel parameter used (see previous mail for mine)
>
"console=ttyAMA0,115200 root=/dev/mmcblk0p1 rw rootwait gpmi_debug_init"


Best Regards
Huang Shijie
> Regards,
> Koen
>
>>
>> Lothar Wa?mann
>> --
>> ___________________________________________________________
>>
>> Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
>> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
>> Gesch?ftsf?hrer: Matthias Kaussen
>> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>>
>> www.karo-electronics.de | info at karo-electronics.de
>> ___________________________________________________________
>>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Koen Beel]

On Fri, Jul 29, 2011 at 11:49 AM, Huang Shijie <b32955@freescale.com> wrote:
> ? 2011?07?29? 15:40, Koen Beel ??:
>>
>> Hi,
>>
>> On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann<LW@karo-electronics.de>
>> ?wrote:
>>>
>>> Hi,
>>>
>>> Koen Beel writes:
>>>>
>>>> Hi,
>>>>
>>>> I have test on mx23evk board. Still see the same issues.
>>>>
>>>> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<b32955@freescale.com>
>>>> ?wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Thanks for your test.
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> It's not really working for me.
>>>>>> I've applied all gpmi-nand driver patches and the dma driver patches.
>>>>>>
>>>>>> I have added following kernel parameters:
>>>>>> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
>>>>>> rootfstype=ubifs gpmi_debug_init
>>>>>>
>>>>>> During boot I get already get DMA timeout:
>>>>>> [ ? ?2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last
>>>>>> DMA
>>>>>> :1
>>>>>> [ ? ?3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
>>>>>> ...
>>>>>> (see log file in attach line 89)
>>>>
>>>> I still see this DMA timeout when booting.
>>>> What kernel parameters do you use? I still use same as above.
>>>>
>>> Do you have an SD card in the system? I'm getting the same error when
>>> accessing an SD card. Without SD card I can use the flash without any
>>> errors.
>>
>> No SD card in the system. At least not on my mx23evk board.
>> My real target hardware has a SDIO wifi chip.
>
> Does it conflict with the GPMI?

Well I don't know if it conflicts. From what Lothar says I assume
there might be a conflict between gpmi and sdio.

For now I see the same problem on both the evk (no sd/sdio card) and
on my real target hardware (fixed sdio chip).

>>
>> Are you also testing on the mx23evk board? Really strange it is not
>> reproducible here then.
>> Anyone using mx23evk please give:
>
> I tested the code in mx23evk.
> After boot the kernel and login the shell, I met a problem:
> ?the flash_eraseall can not run with the log:
> "Floating point exception"
> :(
>
>
>> - revision number of board (I have tested on rev C1)
>
> Revision number is C.
>>
>> - kernel parameter used (see previous mail for mine)
>>
> "console=ttyAMA0,115200 root=/dev/mmcblk0p1 rw rootwait gpmi_debug_init"

You have a rootfs on an SD card? And gpmi is working? No conflicts on
dma or something?
Have you hard coded the mtdparts in the init code? I pass something
like "mtdparts=gpmi-nand:20m(boot),-(user)" as kernel parameter, but
you don't...

>
>
> Best Regards
> Huang Shijie
>>
>> Regards,
>> Koen
>>
>>>
>>> Lothar Wa?mann
>>> --
>>> ___________________________________________________________
>>>
>>> Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
>>> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
>>> Gesch?ftsf?hrer: Matthias Kaussen
>>> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>>>
>>> www.karo-electronics.de | info at karo-electronics.de
>>> ___________________________________________________________
>>>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Huang Shijie]

Hi,
> On Fri, Jul 29, 2011 at 11:49 AM, Huang Shijie<b32955@freescale.com>  wrote:
>> ? 2011?07?29? 15:40, Koen Beel ??:
>>> Hi,
>>>
>>> On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann<LW@karo-electronics.de>
>>>   wrote:
>>>> Hi,
>>>>
>>>> Koen Beel writes:
>>>>> Hi,
>>>>>
>>>>> I have test on mx23evk board. Still see the same issues.
>>>>>
>>>>> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<b32955@freescale.com>
>>>>>   wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Thanks for your test.
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> It's not really working for me.
>>>>>>> I've applied all gpmi-nand driver patches and the dma driver patches.
>>>>>>>
>>>>>>> I have added following kernel parameters:
>>>>>>> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
>>>>>>> rootfstype=ubifs gpmi_debug_init
>>>>>>>
>>>>>>> During boot I get already get DMA timeout:
>>>>>>> [    2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last
>>>>>>> DMA
>>>>>>> :1
>>>>>>> [    3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
>>>>>>> ...
>>>>>>> (see log file in attach line 89)
>>>>> I still see this DMA timeout when booting.
>>>>> What kernel parameters do you use? I still use same as above.
>>>>>
>>>> Do you have an SD card in the system? I'm getting the same error when
>>>> accessing an SD card. Without SD card I can use the flash without any
>>>> errors.
>>> No SD card in the system. At least not on my mx23evk board.
>>> My real target hardware has a SDIO wifi chip.
>> Does it conflict with the GPMI?
> Well I don't know if it conflicts. From what Lothar says I assume
> there might be a conflict between gpmi and sdio.
Yes, the conflict between gpmi and other module(such as SD in MX6Q) is 
THE prime reason
which caused the DMA timeout.

I am debuging the IMX6Q now, and meet the same problem.

> For now I see the same problem on both the evk (no sd/sdio card) and
> on my real target hardware (fixed sdio chip).
>
>>> Are you also testing on the mx23evk board? Really strange it is not
>>> reproducible here then.
>>> Anyone using mx23evk please give:
>> I tested the code in mx23evk.
>> After boot the kernel and login the shell, I met a problem:
>>   the flash_eraseall can not run with the log:
>> "Floating point exception"
>> :(
>>
>>
>>> - revision number of board (I have tested on rev C1)
>> Revision number is C.
>>> - kernel parameter used (see previous mail for mine)
>>>
>> "console=ttyAMA0,115200 root=/dev/mmcblk0p1 rw rootwait gpmi_debug_init"
> You have a rootfs on an SD card? And gpmi is working? No conflicts on
I ever put the rootfs in the NAND. But I put the rootfs in the
SD card now.

The GPMI is working. No confilct on DMA now.
But I do not do much test on the NAND, such as bonnie++.
So it need to further test.

Best Regards
Huang Shijie
> dma or something?
> Have you hard coded the mtdparts in the init code? I pass something
> like "mtdparts=gpmi-nand:20m(boot),-(user)" as kernel parameter, but
> you don't...
>
>>
>> Best Regards
>> Huang Shijie
>>> Regards,
>>> Koen
>>>
>>>> Lothar Wa?mann
>>>> --
>>>> ___________________________________________________________
>>>>
>>>> Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
>>>> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
>>>> Gesch?ftsf?hrer: Matthias Kaussen
>>>> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>>>>
>>>> www.karo-electronics.de | info at karo-electronics.de
>>>> ___________________________________________________________
>>>>
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Shawn Guo]

On Tue, Aug 02, 2011 at 02:19:56PM +0800, Huang Shijie wrote:
> Hi,
> >On Fri, Jul 29, 2011 at 11:49 AM, Huang Shijie<b32955@freescale.com>  wrote:
> >>? 2011?07?29? 15:40, Koen Beel ??:
> >>>Hi,
> >>>
> >>>On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann<LW@karo-electronics.de>
> >>>  wrote:
> >>>>Hi,
> >>>>
> >>>>Koen Beel writes:
> >>>>>Hi,
> >>>>>
> >>>>>I have test on mx23evk board. Still see the same issues.
> >>>>>
> >>>>>On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<b32955@freescale.com>
> >>>>>  wrote:
> >>>>>>Hi,
> >>>>>>
> >>>>>>Thanks for your test.
> >>>>>>
> >>>>>>>Hi,
> >>>>>>>
> >>>>>>>It's not really working for me.
> >>>>>>>I've applied all gpmi-nand driver patches and the dma driver patches.
> >>>>>>>
> >>>>>>>I have added following kernel parameters:
> >>>>>>>mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
> >>>>>>>rootfstype=ubifs gpmi_debug_init
> >>>>>>>
> >>>>>>>During boot I get already get DMA timeout:
> >>>>>>>[    2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last
> >>>>>>>DMA
> >>>>>>>:1
> >>>>>>>[    3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
> >>>>>>>...
> >>>>>>>(see log file in attach line 89)
> >>>>>I still see this DMA timeout when booting.
> >>>>>What kernel parameters do you use? I still use same as above.
> >>>>>
> >>>>Do you have an SD card in the system? I'm getting the same error when
> >>>>accessing an SD card. Without SD card I can use the flash without any
> >>>>errors.
> >>>No SD card in the system. At least not on my mx23evk board.
> >>>My real target hardware has a SDIO wifi chip.
> >>Does it conflict with the GPMI?
> >Well I don't know if it conflicts. From what Lothar says I assume
> >there might be a conflict between gpmi and sdio.
> Yes, the conflict between gpmi and other module(such as SD in MX6Q)
> is THE prime reason
> which caused the DMA timeout.
> 
> I am debuging the IMX6Q now, and meet the same problem.
> 
I do not follow on this.  SD on i.mx6q does not use apbh-dma at all.
How will it conflict with gpmi regarding to dma timeout?

-- 
Regards,
Shawn

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Shawn Guo]

On Tue, Aug 02, 2011 at 02:19:56PM +0800, Huang Shijie wrote:
> Hi,
> >On Fri, Jul 29, 2011 at 11:49 AM, Huang Shijie<b32955@freescale.com>  wrote:
> >>? 2011?07?29? 15:40, Koen Beel ??:
> >>>Hi,
> >>>
> >>>On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann<LW@karo-electronics.de>
> >>>  wrote:
> >>>>Hi,
> >>>>
> >>>>Koen Beel writes:
> >>>>>Hi,
> >>>>>
> >>>>>I have test on mx23evk board. Still see the same issues.
> >>>>>
> >>>>>On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<b32955@freescale.com>
> >>>>>  wrote:
> >>>>>>Hi,
> >>>>>>
> >>>>>>Thanks for your test.
> >>>>>>
> >>>>>>>Hi,
> >>>>>>>
> >>>>>>>It's not really working for me.
> >>>>>>>I've applied all gpmi-nand driver patches and the dma driver patches.
> >>>>>>>
> >>>>>>>I have added following kernel parameters:
> >>>>>>>mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
> >>>>>>>rootfstype=ubifs gpmi_debug_init
> >>>>>>>
> >>>>>>>During boot I get already get DMA timeout:
> >>>>>>>[    2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last
> >>>>>>>DMA
> >>>>>>>:1
> >>>>>>>[    3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
> >>>>>>>...
> >>>>>>>(see log file in attach line 89)
> >>>>>I still see this DMA timeout when booting.
> >>>>>What kernel parameters do you use? I still use same as above.
> >>>>>
> >>>>Do you have an SD card in the system? I'm getting the same error when
> >>>>accessing an SD card. Without SD card I can use the flash without any
> >>>>errors.
> >>>No SD card in the system. At least not on my mx23evk board.
> >>>My real target hardware has a SDIO wifi chip.
> >>Does it conflict with the GPMI?
> >Well I don't know if it conflicts. From what Lothar says I assume
> >there might be a conflict between gpmi and sdio.
> Yes, the conflict between gpmi and other module(such as SD in MX6Q)
> is THE prime reason
> which caused the DMA timeout.
> 
> I am debuging the IMX6Q now, and meet the same problem.
> 
I do not follow on this.  SD on i.mx6q does not use apbh-dma at all.
How will it conflict with gpmi regarding to dma timeout?

-- 
Regards,
Shawn

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Shawn Guo]

On Tue, Aug 02, 2011 at 02:19:56PM +0800, Huang Shijie wrote:
> Hi,
> >On Fri, Jul 29, 2011 at 11:49 AM, Huang Shijie<b32955@freescale.com>  wrote:
> >>? 2011?07?29? 15:40, Koen Beel ??:
> >>>Hi,
> >>>
> >>>On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann<LW@karo-electronics.de>
> >>>  wrote:
> >>>>Hi,
> >>>>
> >>>>Koen Beel writes:
> >>>>>Hi,
> >>>>>
> >>>>>I have test on mx23evk board. Still see the same issues.
> >>>>>
> >>>>>On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<b32955@freescale.com>
> >>>>>  wrote:
> >>>>>>Hi,
> >>>>>>
> >>>>>>Thanks for your test.
> >>>>>>
> >>>>>>>Hi,
> >>>>>>>
> >>>>>>>It's not really working for me.
> >>>>>>>I've applied all gpmi-nand driver patches and the dma driver patches.
> >>>>>>>
> >>>>>>>I have added following kernel parameters:
> >>>>>>>mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
> >>>>>>>rootfstype=ubifs gpmi_debug_init
> >>>>>>>
> >>>>>>>During boot I get already get DMA timeout:
> >>>>>>>[    2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last
> >>>>>>>DMA
> >>>>>>>:1
> >>>>>>>[    3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
> >>>>>>>...
> >>>>>>>(see log file in attach line 89)
> >>>>>I still see this DMA timeout when booting.
> >>>>>What kernel parameters do you use? I still use same as above.
> >>>>>
> >>>>Do you have an SD card in the system? I'm getting the same error when
> >>>>accessing an SD card. Without SD card I can use the flash without any
> >>>>errors.
> >>>No SD card in the system. At least not on my mx23evk board.
> >>>My real target hardware has a SDIO wifi chip.
> >>Does it conflict with the GPMI?
> >Well I don't know if it conflicts. From what Lothar says I assume
> >there might be a conflict between gpmi and sdio.
> Yes, the conflict between gpmi and other module(such as SD in MX6Q)
> is THE prime reason
> which caused the DMA timeout.
> 
> I am debuging the IMX6Q now, and meet the same problem.
> 
I do not follow on this.  SD on i.mx6q does not use apbh-dma at all.
How will it conflict with gpmi regarding to dma timeout?

-- 
Regards,
Shawn

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Huang Shijie]

? 2011?08?02? 16:12, Shawn Guo ??:
> On Tue, Aug 02, 2011 at 02:19:56PM +0800, Huang Shijie wrote:
>> Hi,
>>> On Fri, Jul 29, 2011 at 11:49 AM, Huang Shijie<b32955@freescale.com>   wrote:
>>>> ? 2011?07?29? 15:40, Koen Beel ??:
>>>>> Hi,
>>>>>
>>>>> On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann<LW@karo-electronics.de>
>>>>>   wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Koen Beel writes:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have test on mx23evk board. Still see the same issues.
>>>>>>>
>>>>>>> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<b32955@freescale.com>
>>>>>>>   wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Thanks for your test.
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> It's not really working for me.
>>>>>>>>> I've applied all gpmi-nand driver patches and the dma driver patches.
>>>>>>>>>
>>>>>>>>> I have added following kernel parameters:
>>>>>>>>> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
>>>>>>>>> rootfstype=ubifs gpmi_debug_init
>>>>>>>>>
>>>>>>>>> During boot I get already get DMA timeout:
>>>>>>>>> [    2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last
>>>>>>>>> DMA
>>>>>>>>> :1
>>>>>>>>> [    3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
>>>>>>>>> ...
>>>>>>>>> (see log file in attach line 89)
>>>>>>> I still see this DMA timeout when booting.
>>>>>>> What kernel parameters do you use? I still use same as above.
>>>>>>>
>>>>>> Do you have an SD card in the system? I'm getting the same error when
>>>>>> accessing an SD card. Without SD card I can use the flash without any
>>>>>> errors.
>>>>> No SD card in the system. At least not on my mx23evk board.
>>>>> My real target hardware has a SDIO wifi chip.
>>>> Does it conflict with the GPMI?
>>> Well I don't know if it conflicts. From what Lothar says I assume
>>> there might be a conflict between gpmi and sdio.
>> Yes, the conflict between gpmi and other module(such as SD in MX6Q)
>> is THE prime reason
>> which caused the DMA timeout.
>>
>> I am debuging the IMX6Q now, and meet the same problem.
>>
> I do not follow on this.  SD on i.mx6q does not use apbh-dma at all.
> How will it conflict with gpmi regarding to dma timeout?
>
The SD shares the same lines with GPMI, such NANDF_WE/NANDF_RE, 
NANDF_ALE, NANDF_CS0.
If the SD card is working, the GPMI will not.


Huang Shijie

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Lothar Waßmann]

Hi,

Koen Beel writes:
> Hi,
> 
> On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann <LW@karo-electronics.de> wrote:
> > Hi,
> >
> > Koen Beel writes:
> >> Hi,
> >>
> >> I have test on mx23evk board. Still see the same issues.
> >>
> >> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie <b32955@freescale.com> wrote:
> >> > Hi,
> >> >
> >> > Thanks for your test.
> >> >
> >> >> Hi,
> >> >>
> >> >> It's not really working for me.
> >> >> I've applied all gpmi-nand driver patches and the dma driver patches.
> >> >>
> >> >> I have added following kernel parameters:
> >> >> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
> >> >> rootfstype=ubifs gpmi_debug_init
> >> >>
> >> >> During boot I get already get DMA timeout:
> >> >> [ ? ?2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA
> >> >> :1
> >> >> [ ? ?3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
> >> >> ...
> >> >> (see log file in attach line 89)
> >>
> >> I still see this DMA timeout when booting.
> >> What kernel parameters do you use? I still use same as above.
> >>
> > Do you have an SD card in the system? I'm getting the same error when
> > accessing an SD card. Without SD card I can use the flash without any
> > errors.
> 
> No SD card in the system. At least not on my mx23evk board.
> My real target hardware has a SDIO wifi chip.
> 
> Are you also testing on the mx23evk board? Really strange it is not
> reproducible here then.
> Anyone using mx23evk please give:
> - revision number of board (I have tested on rev C1)
> - kernel parameter used (see previous mail for mine)
> 
It's getting ever more strange. I only have problems with concurrent
access to the flash and SD-card when I do file system based accessed
to the SD card.
A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash
works well, while mounting the SD card and doing an 'ls' produces
immediate BCH DMA timeouts.

Perhaps someone can make anything out of that.


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Koen Beel]

On Fri, Jul 29, 2011 at 2:41 PM, Lothar Wa?mann <LW@karo-electronics.de> wrote:
> Hi,
>
> Koen Beel writes:
>> Hi,
>>
>> On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann <LW@karo-electronics.de> wrote:
>> > Hi,
>> >
>> > Koen Beel writes:
>> >> Hi,
>> >>
>> >> I have test on mx23evk board. Still see the same issues.
>> >>
>> >> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie <b32955@freescale.com> wrote:
>> >> > Hi,
>> >> >
>> >> > Thanks for your test.
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> It's not really working for me.
>> >> >> I've applied all gpmi-nand driver patches and the dma driver patches.
>> >> >>
>> >> >> I have added following kernel parameters:
>> >> >> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
>> >> >> rootfstype=ubifs gpmi_debug_init
>> >> >>
>> >> >> During boot I get already get DMA timeout:
>> >> >> [ ? ?2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA
>> >> >> :1
>> >> >> [ ? ?3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
>> >> >> ...
>> >> >> (see log file in attach line 89)
>> >>
>> >> I still see this DMA timeout when booting.
>> >> What kernel parameters do you use? I still use same as above.
>> >>
>> > Do you have an SD card in the system? I'm getting the same error when
>> > accessing an SD card. Without SD card I can use the flash without any
>> > errors.
>>
>> No SD card in the system. At least not on my mx23evk board.
>> My real target hardware has a SDIO wifi chip.
>>
>> Are you also testing on the mx23evk board? Really strange it is not
>> reproducible here then.
>> Anyone using mx23evk please give:
>> - revision number of board (I have tested on rev C1)
>> - kernel parameter used (see previous mail for mine)
>>
> It's getting ever more strange. I only have problems with concurrent
> access to the flash and SD-card when I do file system based accessed
> to the SD card.
> A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash
> works well, while mounting the SD card and doing an 'ls' produces
> immediate BCH DMA timeouts.
>
> Perhaps someone can make anything out of that.

I have checked and the function dma_irq_callback is never called
during my tests. This means the DMA transfer does not even works once.

Also no clue here ...

>
>
> Lothar Wa?mann
> --
> ___________________________________________________________
>
> Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
> Gesch?ftsf?hrer: Matthias Kaussen
> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>
> www.karo-electronics.de | info at karo-electronics.de
> ___________________________________________________________
>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Marek Vasut]

On Friday, July 29, 2011 05:00:48 PM Koen Beel wrote:
> On Fri, Jul 29, 2011 at 2:41 PM, Lothar Wa?mann <LW@karo-electronics.de> 
wrote:
> > Hi,
> > 
> > Koen Beel writes:
> >> Hi,
> >> 
> >> On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann <LW@karo-electronics.de> 
wrote:
> >> > Hi,
> >> > 
> >> > Koen Beel writes:
> >> >> Hi,
> >> >> 
> >> >> I have test on mx23evk board. Still see the same issues.
> >> >> 
> >> >> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie <b32955@freescale.com> 
wrote:
> >> >> > Hi,
> >> >> > 
> >> >> > Thanks for your test.
> >> >> > 
> >> >> >> Hi,
> >> >> >> 
> >> >> >> It's not really working for me.
> >> >> >> I've applied all gpmi-nand driver patches and the dma driver
> >> >> >> patches.
> >> >> >> 
> >> >> >> I have added following kernel parameters:
> >> >> >> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
> >> >> >> rootfstype=ubifs gpmi_debug_init
> >> >> >> 
> >> >> >> During boot I get already get DMA timeout:
> >> >> >> [    2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout,
> >> >> >> last DMA
> >> >> >> 
> >> >> >> :1
> >> >> >> 
> >> >> >> [    3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
> >> >> >> ...
> >> >> >> (see log file in attach line 89)
> >> >> 
> >> >> I still see this DMA timeout when booting.
> >> >> What kernel parameters do you use? I still use same as above.
> >> > 
> >> > Do you have an SD card in the system? I'm getting the same error when
> >> > accessing an SD card. Without SD card I can use the flash without any
> >> > errors.
> >> 
> >> No SD card in the system. At least not on my mx23evk board.
> >> My real target hardware has a SDIO wifi chip.
> >> 
> >> Are you also testing on the mx23evk board? Really strange it is not
> >> reproducible here then.
> >> Anyone using mx23evk please give:
> >> - revision number of board (I have tested on rev C1)
> >> - kernel parameter used (see previous mail for mine)
> > 
> > It's getting ever more strange. I only have problems with concurrent
> > access to the flash and SD-card when I do file system based accessed
> > to the SD card.
> > A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash
> > works well, while mounting the SD card and doing an 'ls' produces
> > immediate BCH DMA timeouts.
> > 
> > Perhaps someone can make anything out of that.
> 
> I have checked and the function dma_irq_callback is never called
> during my tests. This means the DMA transfer does not even works once.
> 
> Also no clue here ...

Aren't you getting some undervolt on the powerrail for example ? btw the driver 
looks a bit crappy to me, but let's believe it works ;-)

> 
> > Lothar Wa?mann
> > --
> > ___________________________________________________________
> > 
> > Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
> > Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
> > Gesch?ftsf?hrer: Matthias Kaussen
> > Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
> > 
> > www.karo-electronics.de | info at karo-electronics.de
> > ___________________________________________________________
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Koen Beel]

Hi,

Don't think it's a hardware issue. After all it is working on the
mx23evk using the Freescale BSP based on 2.6.35.3.
Now I tested using this kernel command line:
mtdparts=gpmi-nand:20m(boot),-(user) gpmi_debug_init
(So I removed the ubi rootfs stuff, see previous mails).

Its booting fine now without complaining about dma timeouts.

Have tried flash_eraseall /dev/mtd1. Now it's complaining and thinking
all blocks are bad. So a "flash_erase: Skipping bad block at 1db00000"
message for every erase block.
Writing 1 to /sys/devices/platform/imx23-gpmi-nand/ignorebad, makes to
go a little further giving 'only one' error but I doubt it's working
at all. See attached log file.

When the trying ubiformat /dev/mtd1 its stopping with a dma timeout.
Every subsequent action (e.g. using ubiformat or flash_eraseall) using
that dma channel is failing.
I have put a printk in mxs-dma.c around line 387:

    if (mxs_chan->status == DMA_IN_PROGRESS && !append)
    {
        pr_err("dma already in progess!\n");
        return NULL;
    }

I see that printk also in the log file in attach. Seems like the
mxs-dma is failing at some point and for the rest of the time always
keeps it's status at DMA_IN_PROGRESS

Any input or feedback is welcome.

Regards,
Koen


On Sun, Jul 31, 2011 at 3:51 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> On Friday, July 29, 2011 05:00:48 PM Koen Beel wrote:
>> On Fri, Jul 29, 2011 at 2:41 PM, Lothar Wa?mann <LW@karo-electronics.de>
> wrote:
>> > Hi,
>> >
>> > Koen Beel writes:
>> >> Hi,
>> >>
>> >> On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann <LW@karo-electronics.de>
> wrote:
>> >> > Hi,
>> >> >
>> >> > Koen Beel writes:
>> >> >> Hi,
>> >> >>
>> >> >> I have test on mx23evk board. Still see the same issues.
>> >> >>
>> >> >> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie <b32955@freescale.com>
> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > Thanks for your test.
>> >> >> >
>> >> >> >> Hi,
>> >> >> >>
>> >> >> >> It's not really working for me.
>> >> >> >> I've applied all gpmi-nand driver patches and the dma driver
>> >> >> >> patches.
>> >> >> >>
>> >> >> >> I have added following kernel parameters:
>> >> >> >> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
>> >> >> >> rootfstype=ubifs gpmi_debug_init
>> >> >> >>
>> >> >> >> During boot I get already get DMA timeout:
>> >> >> >> [ ? ?2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout,
>> >> >> >> last DMA
>> >> >> >>
>> >> >> >> :1
>> >> >> >>
>> >> >> >> [ ? ?3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
>> >> >> >> ...
>> >> >> >> (see log file in attach line 89)
>> >> >>
>> >> >> I still see this DMA timeout when booting.
>> >> >> What kernel parameters do you use? I still use same as above.
>> >> >
>> >> > Do you have an SD card in the system? I'm getting the same error when
>> >> > accessing an SD card. Without SD card I can use the flash without any
>> >> > errors.
>> >>
>> >> No SD card in the system. At least not on my mx23evk board.
>> >> My real target hardware has a SDIO wifi chip.
>> >>
>> >> Are you also testing on the mx23evk board? Really strange it is not
>> >> reproducible here then.
>> >> Anyone using mx23evk please give:
>> >> - revision number of board (I have tested on rev C1)
>> >> - kernel parameter used (see previous mail for mine)
>> >
>> > It's getting ever more strange. I only have problems with concurrent
>> > access to the flash and SD-card when I do file system based accessed
>> > to the SD card.
>> > A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash
>> > works well, while mounting the SD card and doing an 'ls' produces
>> > immediate BCH DMA timeouts.
>> >
>> > Perhaps someone can make anything out of that.
>>
>> I have checked and the function dma_irq_callback is never called
>> during my tests. This means the DMA transfer does not even works once.
>>
>> Also no clue here ...
>
> Aren't you getting some undervolt on the powerrail for example ? btw the driver
> looks a bit crappy to me, but let's believe it works ;-)
>
>>
>> > Lothar Wa?mann
>> > --
>> > ___________________________________________________________
>> >
>> > Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
>> > Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
>> > Gesch?ftsf?hrer: Matthias Kaussen
>> > Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>> >
>> > www.karo-electronics.de | info at karo-electronics.de
>> > ___________________________________________________________
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log1
Type: application/octet-stream
Size: 2644 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110801/32011204/attachment-0001.obj>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Huang Shijie]

Hi,
> Hi,
>
> Don't think it's a hardware issue. After all it is working on the
> mx23evk using the Freescale BSP based on 2.6.35.3.
I doubt the Freescale BSP has fix the conflict, while the community 
kernel does not
fix it.
Anyway, I will do more test on the mx23 board myself.



> Now I tested using this kernel command line:
> mtdparts=gpmi-nand:20m(boot),-(user) gpmi_debug_init
> (So I removed the ubi rootfs stuff, see previous mails).
>
> Its booting fine now without complaining about dma timeouts.
ok.
> Have tried flash_eraseall /dev/mtd1. Now it's complaining and thinking
> all blocks are bad. So a "flash_erase: Skipping bad block at 1db00000"
> message for every erase block.
> Writing 1 to /sys/devices/platform/imx23-gpmi-nand/ignorebad, makes to
This is a very dangerous interface.

> go a little further giving 'only one' error but I doubt it's working
> at all. See attached log file.
>
> When the trying ubiformat /dev/mtd1 its stopping with a dma timeout.
echo 0x20 > /sys/devices/platform/imx23-gpmi-nand/gpmi_debug

to show the GPMI register when the DMA timeout occurs.


Best Regards
Huang Shijie
> Every subsequent action (e.g. using ubiformat or flash_eraseall) using
> that dma channel is failing.
> I have put a printk in mxs-dma.c around line 387:
>
>      if (mxs_chan->status == DMA_IN_PROGRESS&&  !append)
>      {
>          pr_err("dma already in progess!\n");
>          return NULL;
>      }
>
> I see that printk also in the log file in attach. Seems like the
> mxs-dma is failing at some point and for the rest of the time always
> keeps it's status at DMA_IN_PROGRESS
>
> Any input or feedback is welcome.
>
> Regards,
> Koen
>
>
> On Sun, Jul 31, 2011 at 3:51 PM, Marek Vasut<marek.vasut@gmail.com>  wrote:
>> On Friday, July 29, 2011 05:00:48 PM Koen Beel wrote:
>>> On Fri, Jul 29, 2011 at 2:41 PM, Lothar Wa?mann<LW@karo-electronics.de>
>> wrote:
>>>> Hi,
>>>>
>>>> Koen Beel writes:
>>>>> Hi,
>>>>>
>>>>> On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann<LW@karo-electronics.de>
>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Koen Beel writes:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have test on mx23evk board. Still see the same issues.
>>>>>>>
>>>>>>> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<b32955@freescale.com>
>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Thanks for your test.
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> It's not really working for me.
>>>>>>>>> I've applied all gpmi-nand driver patches and the dma driver
>>>>>>>>> patches.
>>>>>>>>>
>>>>>>>>> I have added following kernel parameters:
>>>>>>>>> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
>>>>>>>>> rootfstype=ubifs gpmi_debug_init
>>>>>>>>>
>>>>>>>>> During boot I get already get DMA timeout:
>>>>>>>>> [    2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout,
>>>>>>>>> last DMA
>>>>>>>>>
>>>>>>>>> :1
>>>>>>>>>
>>>>>>>>> [    3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
>>>>>>>>> ...
>>>>>>>>> (see log file in attach line 89)
>>>>>>> I still see this DMA timeout when booting.
>>>>>>> What kernel parameters do you use? I still use same as above.
>>>>>> Do you have an SD card in the system? I'm getting the same error when
>>>>>> accessing an SD card. Without SD card I can use the flash without any
>>>>>> errors.
>>>>> No SD card in the system. At least not on my mx23evk board.
>>>>> My real target hardware has a SDIO wifi chip.
>>>>>
>>>>> Are you also testing on the mx23evk board? Really strange it is not
>>>>> reproducible here then.
>>>>> Anyone using mx23evk please give:
>>>>> - revision number of board (I have tested on rev C1)
>>>>> - kernel parameter used (see previous mail for mine)
>>>> It's getting ever more strange. I only have problems with concurrent
>>>> access to the flash and SD-card when I do file system based accessed
>>>> to the SD card.
>>>> A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash
>>>> works well, while mounting the SD card and doing an 'ls' produces
>>>> immediate BCH DMA timeouts.
>>>>
>>>> Perhaps someone can make anything out of that.
>>> I have checked and the function dma_irq_callback is never called
>>> during my tests. This means the DMA transfer does not even works once.
>>>
>>> Also no clue here ...
>> Aren't you getting some undervolt on the powerrail for example ? btw the driver
>> looks a bit crappy to me, but let's believe it works ;-)
>>
>>>> Lothar Wa?mann
>>>> --
>>>> ___________________________________________________________
>>>>
>>>> Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
>>>> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
>>>> Gesch?ftsf?hrer: Matthias Kaussen
>>>> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>>>>
>>>> www.karo-electronics.de | info at karo-electronics.de
>>>> ___________________________________________________________
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Koen Beel]

Hi,

On Tue, Aug 2, 2011 at 8:37 AM, Huang Shijie <b32955@freescale.com> wrote:
> Hi,
>>
>> Hi,
>>
>> Don't think it's a hardware issue. After all it is working on the
>> mx23evk using the Freescale BSP based on 2.6.35.3.
>
> I doubt the Freescale BSP has fix the conflict, while the community kernel
> does not
> fix it.
> Anyway, I will do more test on the mx23 board myself.

Strange indeed. I suspect that the BSP used another way to mark bad blocks.

>
>
>
>> Now I tested using this kernel command line:
>> mtdparts=gpmi-nand:20m(boot),-(user) gpmi_debug_init
>> (So I removed the ubi rootfs stuff, see previous mails).
>>
>> Its booting fine now without complaining about dma timeouts.
>
> ok.

That's mainly because the ubi stuff is not done at startup.

>>
>> Have tried flash_eraseall /dev/mtd1. Now it's complaining and thinking
>> all blocks are bad. So a "flash_erase: Skipping bad block at 1db00000"
>> message for every erase block.
>> Writing 1 to /sys/devices/platform/imx23-gpmi-nand/ignorebad, makes to
>
> This is a very dangerous interface.

I know but it solved an issue here. Now flash_eraseall seems to be
working again without that ignorebad turned on (only finds one bad
erase blcok).
Again: I suspect that the BSP used another way to mark bad blocks.

>
>> go a little further giving 'only one' error but I doubt it's working
>> at all. See attached log file.
>>
>> When the trying ubiformat /dev/mtd1 its stopping with a dma timeout.
>
> echo 0x20 > /sys/devices/platform/imx23-gpmi-nand/gpmi_debug
>
> to show the GPMI register when the DMA timeout occurs.

Don't have this sysfs interface here. I also don't see where it is
registered in the driver code.
Anyway I have hardcoded GPMI_DEBUG_CRAZY in gpmi_debug_setup.

log file attached.

Regards,
Koen

>
>
> Best Regards
> Huang Shijie
>>
>> Every subsequent action (e.g. using ubiformat or flash_eraseall) using
>> that dma channel is failing.
>> I have put a printk in mxs-dma.c around line 387:
>>
>> ? ? if (mxs_chan->status == DMA_IN_PROGRESS&& ?!append)
>> ? ? {
>> ? ? ? ? pr_err("dma already in progess!\n");
>> ? ? ? ? return NULL;
>> ? ? }
>>
>> I see that printk also in the log file in attach. Seems like the
>> mxs-dma is failing at some point and for the rest of the time always
>> keeps it's status at DMA_IN_PROGRESS
>>
>> Any input or feedback is welcome.
>>
>> Regards,
>> Koen
>>
>>
>> On Sun, Jul 31, 2011 at 3:51 PM, Marek Vasut<marek.vasut@gmail.com>
>> ?wrote:
>>>
>>> On Friday, July 29, 2011 05:00:48 PM Koen Beel wrote:
>>>>
>>>> On Fri, Jul 29, 2011 at 2:41 PM, Lothar Wa?mann<LW@karo-electronics.de>
>>>
>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Koen Beel writes:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Fri, Jul 29, 2011 at 9:20 AM, Lothar
>>>>>> Wa?mann<LW@karo-electronics.de>
>>>
>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Koen Beel writes:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have test on mx23evk board. Still see the same issues.
>>>>>>>>
>>>>>>>> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<b32955@freescale.com>
>>>
>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Thanks for your test.
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> It's not really working for me.
>>>>>>>>>> I've applied all gpmi-nand driver patches and the dma driver
>>>>>>>>>> patches.
>>>>>>>>>>
>>>>>>>>>> I have added following kernel parameters:
>>>>>>>>>> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
>>>>>>>>>> rootfstype=ubifs gpmi_debug_init
>>>>>>>>>>
>>>>>>>>>> During boot I get already get DMA timeout:
>>>>>>>>>> [ ? ?2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout,
>>>>>>>>>> last DMA
>>>>>>>>>>
>>>>>>>>>> :1
>>>>>>>>>>
>>>>>>>>>> [ ? ?3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
>>>>>>>>>> ...
>>>>>>>>>> (see log file in attach line 89)
>>>>>>>>
>>>>>>>> I still see this DMA timeout when booting.
>>>>>>>> What kernel parameters do you use? I still use same as above.
>>>>>>>
>>>>>>> Do you have an SD card in the system? I'm getting the same error when
>>>>>>> accessing an SD card. Without SD card I can use the flash without any
>>>>>>> errors.
>>>>>>
>>>>>> No SD card in the system. At least not on my mx23evk board.
>>>>>> My real target hardware has a SDIO wifi chip.
>>>>>>
>>>>>> Are you also testing on the mx23evk board? Really strange it is not
>>>>>> reproducible here then.
>>>>>> Anyone using mx23evk please give:
>>>>>> - revision number of board (I have tested on rev C1)
>>>>>> - kernel parameter used (see previous mail for mine)
>>>>>
>>>>> It's getting ever more strange. I only have problems with concurrent
>>>>> access to the flash and SD-card when I do file system based accessed
>>>>> to the SD card.
>>>>> A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash
>>>>> works well, while mounting the SD card and doing an 'ls' produces
>>>>> immediate BCH DMA timeouts.
>>>>>
>>>>> Perhaps someone can make anything out of that.
>>>>
>>>> I have checked and the function dma_irq_callback is never called
>>>> during my tests. This means the DMA transfer does not even works once.
>>>>
>>>> Also no clue here ...
>>>
>>> Aren't you getting some undervolt on the powerrail for example ? btw the
>>> driver
>>> looks a bit crappy to me, but let's believe it works ;-)
>>>
>>>>> Lothar Wa?mann
>>>>> --
>>>>> ___________________________________________________________
>>>>>
>>>>> Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
>>>>> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
>>>>> Gesch?ftsf?hrer: Matthias Kaussen
>>>>> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>>>>>
>>>>> www.karo-electronics.de | info at karo-electronics.de
>>>>> ___________________________________________________________
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> linux-arm-kernel at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log2
Type: application/octet-stream
Size: 2896 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110802/c00871d9/attachment.obj>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Huang Shijie]

Hi,
> Hi,
>
> On Tue, Aug 2, 2011 at 8:37 AM, Huang Shijie<b32955@freescale.com>  wrote:
>> Hi,
>>> Hi,
>>>
>>> Don't think it's a hardware issue. After all it is working on the
>>> mx23evk using the Freescale BSP based on 2.6.35.3.
>> I doubt the Freescale BSP has fix the conflict, while the community kernel
>> does not
>> fix it.
>> Anyway, I will do more test on the mx23 board myself.
> Strange indeed. I suspect that the BSP used another way to mark bad blocks.
>
>>
>>
>>> Now I tested using this kernel command line:
>>> mtdparts=gpmi-nand:20m(boot),-(user) gpmi_debug_init
>>> (So I removed the ubi rootfs stuff, see previous mails).
>>>
>>> Its booting fine now without complaining about dma timeouts.
>> ok.
> That's mainly because the ubi stuff is not done at startup.
>
>>> Have tried flash_eraseall /dev/mtd1. Now it's complaining and thinking
>>> all blocks are bad. So a "flash_erase: Skipping bad block at 1db00000"
>>> message for every erase block.
>>> Writing 1 to /sys/devices/platform/imx23-gpmi-nand/ignorebad, makes to
>> This is a very dangerous interface.
> I know but it solved an issue here. Now flash_eraseall seems to be
> working again without that ignorebad turned on (only finds one bad
> erase blcok).
Could you mail me your flash_eraseall?
Mine  does not work.

so I can test your flash_eraseall first.

Best Regards
Huang Shijie
> Again: I suspect that the BSP used another way to mark bad blocks.
>
>>> go a little further giving 'only one' error but I doubt it's working
>>> at all. See attached log file.
>>>
>>> When the trying ubiformat /dev/mtd1 its stopping with a dma timeout.
>> echo 0x20>  /sys/devices/platform/imx23-gpmi-nand/gpmi_debug
>>
>> to show the GPMI register when the DMA timeout occurs.
> Don't have this sysfs interface here. I also don't see where it is
> registered in the driver code.
> Anyway I have hardcoded GPMI_DEBUG_CRAZY in gpmi_debug_setup.
>
> log file attached.
>
> Regards,
> Koen
>
>>
>> Best Regards
>> Huang Shijie
>>> Every subsequent action (e.g. using ubiformat or flash_eraseall) using
>>> that dma channel is failing.
>>> I have put a printk in mxs-dma.c around line 387:
>>>
>>>      if (mxs_chan->status == DMA_IN_PROGRESS&&    !append)
>>>      {
>>>          pr_err("dma already in progess!\n");
>>>          return NULL;
>>>      }
>>>
>>> I see that printk also in the log file in attach. Seems like the
>>> mxs-dma is failing at some point and for the rest of the time always
>>> keeps it's status at DMA_IN_PROGRESS
>>>
>>> Any input or feedback is welcome.
>>>
>>> Regards,
>>> Koen
>>>
>>>
>>> On Sun, Jul 31, 2011 at 3:51 PM, Marek Vasut<marek.vasut@gmail.com>
>>>   wrote:
>>>> On Friday, July 29, 2011 05:00:48 PM Koen Beel wrote:
>>>>> On Fri, Jul 29, 2011 at 2:41 PM, Lothar Wa?mann<LW@karo-electronics.de>
>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Koen Beel writes:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Fri, Jul 29, 2011 at 9:20 AM, Lothar
>>>>>>> Wa?mann<LW@karo-electronics.de>
>>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Koen Beel writes:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I have test on mx23evk board. Still see the same issues.
>>>>>>>>>
>>>>>>>>> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<b32955@freescale.com>
>>>> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Thanks for your test.
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> It's not really working for me.
>>>>>>>>>>> I've applied all gpmi-nand driver patches and the dma driver
>>>>>>>>>>> patches.
>>>>>>>>>>>
>>>>>>>>>>> I have added following kernel parameters:
>>>>>>>>>>> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
>>>>>>>>>>> rootfstype=ubifs gpmi_debug_init
>>>>>>>>>>>
>>>>>>>>>>> During boot I get already get DMA timeout:
>>>>>>>>>>> [    2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout,
>>>>>>>>>>> last DMA
>>>>>>>>>>>
>>>>>>>>>>> :1
>>>>>>>>>>>
>>>>>>>>>>> [    3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
>>>>>>>>>>> ...
>>>>>>>>>>> (see log file in attach line 89)
>>>>>>>>> I still see this DMA timeout when booting.
>>>>>>>>> What kernel parameters do you use? I still use same as above.
>>>>>>>> Do you have an SD card in the system? I'm getting the same error when
>>>>>>>> accessing an SD card. Without SD card I can use the flash without any
>>>>>>>> errors.
>>>>>>> No SD card in the system. At least not on my mx23evk board.
>>>>>>> My real target hardware has a SDIO wifi chip.
>>>>>>>
>>>>>>> Are you also testing on the mx23evk board? Really strange it is not
>>>>>>> reproducible here then.
>>>>>>> Anyone using mx23evk please give:
>>>>>>> - revision number of board (I have tested on rev C1)
>>>>>>> - kernel parameter used (see previous mail for mine)
>>>>>> It's getting ever more strange. I only have problems with concurrent
>>>>>> access to the flash and SD-card when I do file system based accessed
>>>>>> to the SD card.
>>>>>> A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash
>>>>>> works well, while mounting the SD card and doing an 'ls' produces
>>>>>> immediate BCH DMA timeouts.
>>>>>>
>>>>>> Perhaps someone can make anything out of that.
>>>>> I have checked and the function dma_irq_callback is never called
>>>>> during my tests. This means the DMA transfer does not even works once.
>>>>>
>>>>> Also no clue here ...
>>>> Aren't you getting some undervolt on the powerrail for example ? btw the
>>>> driver
>>>> looks a bit crappy to me, but let's believe it works ;-)
>>>>
>>>>>> Lothar Wa?mann
>>>>>> --
>>>>>> ___________________________________________________________
>>>>>>
>>>>>> Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
>>>>>> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
>>>>>> Gesch?ftsf?hrer: Matthias Kaussen
>>>>>> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>>>>>>
>>>>>> www.karo-electronics.de | info at karo-electronics.de
>>>>>> ___________________________________________________________
>>>>> _______________________________________________
>>>>> linux-arm-kernel mailing list
>>>>> linux-arm-kernel at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Koen Beel]

Hi,

On Tue, Aug 2, 2011 at 9:44 AM, Huang Shijie <b32955@freescale.com> wrote:
> Hi,
>>
>> Hi,
>>
>> On Tue, Aug 2, 2011 at 8:37 AM, Huang Shijie<b32955@freescale.com> ?wrote:
>>>
>>> Hi,
>>>>
>>>> Hi,
>>>>
>>>> Don't think it's a hardware issue. After all it is working on the
>>>> mx23evk using the Freescale BSP based on 2.6.35.3.
>>>
>>> I doubt the Freescale BSP has fix the conflict, while the community
>>> kernel
>>> does not
>>> fix it.
>>> Anyway, I will do more test on the mx23 board myself.
>>
>> Strange indeed. I suspect that the BSP used another way to mark bad
>> blocks.
>>
>>>
>>>
>>>> Now I tested using this kernel command line:
>>>> mtdparts=gpmi-nand:20m(boot),-(user) gpmi_debug_init
>>>> (So I removed the ubi rootfs stuff, see previous mails).
>>>>
>>>> Its booting fine now without complaining about dma timeouts.
>>>
>>> ok.
>>
>> That's mainly because the ubi stuff is not done at startup.
>>
>>>> Have tried flash_eraseall /dev/mtd1. Now it's complaining and thinking
>>>> all blocks are bad. So a "flash_erase: Skipping bad block at 1db00000"
>>>> message for every erase block.
>>>> Writing 1 to /sys/devices/platform/imx23-gpmi-nand/ignorebad, makes to
>>>
>>> This is a very dangerous interface.
>>
>> I know but it solved an issue here. Now flash_eraseall seems to be
>> working again without that ignorebad turned on (only finds one bad
>> erase blcok).
>
> Could you mail me your flash_eraseall?
> Mine ?does not work.

You want my flash_eraseall binary?

I build all userspace, kernel, bootloader and toolchain using
buildroot ( http://buildroot.uclibc.org/download.html ), which also
includes all flash tools like flash_eraseall and ubiformat. In the
buildroot menuconfig check the packages under 'Package Selection for
the target > Hardware handling > mtd/jffs2 utilities'
Buildroot will build everything needed to get a working system,
including toolchain, uclibc, ... I really recommend that.

Right now I use a kernel with the full rootfs as initramfs (standard
option in buildroot). I just load the uImage (contains kernel and
initramfs) using tftp in uboot. This way I'm not dependent on
mmc/nfs/nand (no eth or mmc on my actual target and nand/ubi not yet
working). Only downside is that I use some memory for it and I don't
have any persistent storage on the rootfs right now.

I have adapted buildroot a little to build the kernel out of tree.

Anyway, if you want my flash_eraseall binary, see attachment.

Regards,
Koen

>
> so I can test your flash_eraseall first.
>
> Best Regards
> Huang Shijie
>>
>> Again: I suspect that the BSP used another way to mark bad blocks.
>>
>>>> go a little further giving 'only one' error but I doubt it's working
>>>> at all. See attached log file.
>>>>
>>>> When the trying ubiformat /dev/mtd1 its stopping with a dma timeout.
>>>
>>> echo 0x20> ?/sys/devices/platform/imx23-gpmi-nand/gpmi_debug
>>>
>>> to show the GPMI register when the DMA timeout occurs.
>>
>> Don't have this sysfs interface here. I also don't see where it is
>> registered in the driver code.
>> Anyway I have hardcoded GPMI_DEBUG_CRAZY in gpmi_debug_setup.
>>
>> log file attached.
>>
>> Regards,
>> Koen
>>
>>>
>>> Best Regards
>>> Huang Shijie
>>>>
>>>> Every subsequent action (e.g. using ubiformat or flash_eraseall) using
>>>> that dma channel is failing.
>>>> I have put a printk in mxs-dma.c around line 387:
>>>>
>>>> ? ? if (mxs_chan->status == DMA_IN_PROGRESS&& ? ?!append)
>>>> ? ? {
>>>> ? ? ? ? pr_err("dma already in progess!\n");
>>>> ? ? ? ? return NULL;
>>>> ? ? }
>>>>
>>>> I see that printk also in the log file in attach. Seems like the
>>>> mxs-dma is failing at some point and for the rest of the time always
>>>> keeps it's status at DMA_IN_PROGRESS
>>>>
>>>> Any input or feedback is welcome.
>>>>
>>>> Regards,
>>>> Koen
>>>>
>>>>
>>>> On Sun, Jul 31, 2011 at 3:51 PM, Marek Vasut<marek.vasut@gmail.com>
>>>> ?wrote:
>>>>>
>>>>> On Friday, July 29, 2011 05:00:48 PM Koen Beel wrote:
>>>>>>
>>>>>> On Fri, Jul 29, 2011 at 2:41 PM, Lothar
>>>>>> Wa?mann<LW@karo-electronics.de>
>>>>>
>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Koen Beel writes:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Fri, Jul 29, 2011 at 9:20 AM, Lothar
>>>>>>>> Wa?mann<LW@karo-electronics.de>
>>>>>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Koen Beel writes:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I have test on mx23evk board. Still see the same issues.
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 27, 2011 at 3:53 AM, Huang
>>>>>>>>>> Shijie<b32955@freescale.com>
>>>>>
>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for your test.
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> It's not really working for me.
>>>>>>>>>>>> I've applied all gpmi-nand driver patches and the dma driver
>>>>>>>>>>>> patches.
>>>>>>>>>>>>
>>>>>>>>>>>> I have added following kernel parameters:
>>>>>>>>>>>> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
>>>>>>>>>>>> rootfstype=ubifs gpmi_debug_init
>>>>>>>>>>>>
>>>>>>>>>>>> During boot I get already get DMA timeout:
>>>>>>>>>>>> [ ? ?2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout,
>>>>>>>>>>>> last DMA
>>>>>>>>>>>>
>>>>>>>>>>>> :1
>>>>>>>>>>>>
>>>>>>>>>>>> [ ? ?3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
>>>>>>>>>>>> ...
>>>>>>>>>>>> (see log file in attach line 89)
>>>>>>>>>>
>>>>>>>>>> I still see this DMA timeout when booting.
>>>>>>>>>> What kernel parameters do you use? I still use same as above.
>>>>>>>>>
>>>>>>>>> Do you have an SD card in the system? I'm getting the same error
>>>>>>>>> when
>>>>>>>>> accessing an SD card. Without SD card I can use the flash without
>>>>>>>>> any
>>>>>>>>> errors.
>>>>>>>>
>>>>>>>> No SD card in the system. At least not on my mx23evk board.
>>>>>>>> My real target hardware has a SDIO wifi chip.
>>>>>>>>
>>>>>>>> Are you also testing on the mx23evk board? Really strange it is not
>>>>>>>> reproducible here then.
>>>>>>>> Anyone using mx23evk please give:
>>>>>>>> - revision number of board (I have tested on rev C1)
>>>>>>>> - kernel parameter used (see previous mail for mine)
>>>>>>>
>>>>>>> It's getting ever more strange. I only have problems with concurrent
>>>>>>> access to the flash and SD-card when I do file system based accessed
>>>>>>> to the SD card.
>>>>>>> A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash
>>>>>>> works well, while mounting the SD card and doing an 'ls' produces
>>>>>>> immediate BCH DMA timeouts.
>>>>>>>
>>>>>>> Perhaps someone can make anything out of that.
>>>>>>
>>>>>> I have checked and the function dma_irq_callback is never called
>>>>>> during my tests. This means the DMA transfer does not even works once.
>>>>>>
>>>>>> Also no clue here ...
>>>>>
>>>>> Aren't you getting some undervolt on the powerrail for example ? btw
>>>>> the
>>>>> driver
>>>>> looks a bit crappy to me, but let's believe it works ;-)
>>>>>
>>>>>>> Lothar Wa?mann
>>>>>>> --
>>>>>>> ___________________________________________________________
>>>>>>>
>>>>>>> Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
>>>>>>> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
>>>>>>> Gesch?ftsf?hrer: Matthias Kaussen
>>>>>>> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>>>>>>>
>>>>>>> www.karo-electronics.de | info at karo-electronics.de
>>>>>>> ___________________________________________________________
>>>>>>
>>>>>> _______________________________________________
>>>>>> linux-arm-kernel mailing list
>>>>>> linux-arm-kernel at lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flash_eraseall
Type: application/octet-stream
Size: 149 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110802/83a12a4e/attachment.obj>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Huang Shijie]

Hi Koen:

I tested the driver in mx23evk board, and I do not find the DMA-timeout 
error.

The following is my test environment:
[0] Hardware:
        MX23EVK PCB REV C
[1] SW:
     kernel:git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi
     .config: my_config , you can find it in my previous email.
     cmdline: console=ttyAMA0,115200 root=/dev/mmcblk0p1 rw rootwait 
gpmi_debug_init mtdparts=gpmi-nand:20m(boot),-(user)

[2] test shell script:
================================

echo 0x20 > /sys/module/gpmi_nand/parameters/gpmi_debug
flash_eraseall /dev/mtd1
ubiformat /dev/mtd1
flash_eraseall /dev/mtd1
ubiattach /dev/ubi_ctrl -m 1
ubimkvol /dev/ubi0 -N test -m
mount -t ubifs ubi0:test tmp
bonnie++ -d tmp -u 0 -s 2 -r 1
bonnie++ -d tmp -u 0 -s 2 -r 1
bonnie++ -d tmp -u 0 -s 2 -r 1
umount tmp
ubidetach /dev/ubi_ctrl -m 1

================================

[3] conclusion
    It runs well in my mx23 board, and no DMA-TIMEOUT occur.
I think there is some conflict in your board.

BTW:
    I split the MTD to 20M and (the rest size).
The flash_eraseall works well.
If i do not split the MTD, the flash_eraseall will not work.
I guest overflow occurs in some place.

Best Regards
Huang Shijie


> On Tue, Aug 2, 2011 at 8:37 AM, Huang Shijie<b32955@freescale.com>  wrote:
>> Hi,
>>> Hi,
>>>
>>> Don't think it's a hardware issue. After all it is working on the
>>> mx23evk using the Freescale BSP based on 2.6.35.3.
>> I doubt the Freescale BSP has fix the conflict, while the community kernel
>> does not
>> fix it.
>> Anyway, I will do more test on the mx23 board myself.
> Strange indeed. I suspect that the BSP used another way to mark bad blocks.
>
>>
>>
>>> Now I tested using this kernel command line:
>>> mtdparts=gpmi-nand:20m(boot),-(user) gpmi_debug_init
>>> (So I removed the ubi rootfs stuff, see previous mails).
>>>
>>> Its booting fine now without complaining about dma timeouts.
>> ok.
> That's mainly because the ubi stuff is not done at startup.
>
>>> Have tried flash_eraseall /dev/mtd1. Now it's complaining and thinking
>>> all blocks are bad. So a "flash_erase: Skipping bad block at 1db00000"
>>> message for every erase block.
>>> Writing 1 to /sys/devices/platform/imx23-gpmi-nand/ignorebad, makes to
>> This is a very dangerous interface.
> I know but it solved an issue here. Now flash_eraseall seems to be
> working again without that ignorebad turned on (only finds one bad
> erase blcok).
> Again: I suspect that the BSP used another way to mark bad blocks.
>
>>> go a little further giving 'only one' error but I doubt it's working
>>> at all. See attached log file.
>>>
>>> When the trying ubiformat /dev/mtd1 its stopping with a dma timeout.
>> echo 0x20>  /sys/devices/platform/imx23-gpmi-nand/gpmi_debug
>>
>> to show the GPMI register when the DMA timeout occurs.
> Don't have this sysfs interface here. I also don't see where it is
> registered in the driver code.
> Anyway I have hardcoded GPMI_DEBUG_CRAZY in gpmi_debug_setup.
>
> log file attached.
>
> Regards,
> Koen
>
>>
>> Best Regards
>> Huang Shijie
>>> Every subsequent action (e.g. using ubiformat or flash_eraseall) using
>>> that dma channel is failing.
>>> I have put a printk in mxs-dma.c around line 387:
>>>
>>>      if (mxs_chan->status == DMA_IN_PROGRESS&&    !append)
>>>      {
>>>          pr_err("dma already in progess!\n");
>>>          return NULL;
>>>      }
>>>
>>> I see that printk also in the log file in attach. Seems like the
>>> mxs-dma is failing at some point and for the rest of the time always
>>> keeps it's status at DMA_IN_PROGRESS
>>>
>>> Any input or feedback is welcome.
>>>
>>> Regards,
>>> Koen
>>>
>>>
>>> On Sun, Jul 31, 2011 at 3:51 PM, Marek Vasut<marek.vasut@gmail.com>
>>>   wrote:
>>>> On Friday, July 29, 2011 05:00:48 PM Koen Beel wrote:
>>>>> On Fri, Jul 29, 2011 at 2:41 PM, Lothar Wa?mann<LW@karo-electronics.de>
>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Koen Beel writes:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Fri, Jul 29, 2011 at 9:20 AM, Lothar
>>>>>>> Wa?mann<LW@karo-electronics.de>
>>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Koen Beel writes:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I have test on mx23evk board. Still see the same issues.
>>>>>>>>>
>>>>>>>>> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<b32955@freescale.com>
>>>> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Thanks for your test.
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> It's not really working for me.
>>>>>>>>>>> I've applied all gpmi-nand driver patches and the dma driver
>>>>>>>>>>> patches.
>>>>>>>>>>>
>>>>>>>>>>> I have added following kernel parameters:
>>>>>>>>>>> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
>>>>>>>>>>> rootfstype=ubifs gpmi_debug_init
>>>>>>>>>>>
>>>>>>>>>>> During boot I get already get DMA timeout:
>>>>>>>>>>> [    2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout,
>>>>>>>>>>> last DMA
>>>>>>>>>>>
>>>>>>>>>>> :1
>>>>>>>>>>>
>>>>>>>>>>> [    3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
>>>>>>>>>>> ...
>>>>>>>>>>> (see log file in attach line 89)
>>>>>>>>> I still see this DMA timeout when booting.
>>>>>>>>> What kernel parameters do you use? I still use same as above.
>>>>>>>> Do you have an SD card in the system? I'm getting the same error when
>>>>>>>> accessing an SD card. Without SD card I can use the flash without any
>>>>>>>> errors.
>>>>>>> No SD card in the system. At least not on my mx23evk board.
>>>>>>> My real target hardware has a SDIO wifi chip.
>>>>>>>
>>>>>>> Are you also testing on the mx23evk board? Really strange it is not
>>>>>>> reproducible here then.
>>>>>>> Anyone using mx23evk please give:
>>>>>>> - revision number of board (I have tested on rev C1)
>>>>>>> - kernel parameter used (see previous mail for mine)
>>>>>> It's getting ever more strange. I only have problems with concurrent
>>>>>> access to the flash and SD-card when I do file system based accessed
>>>>>> to the SD card.
>>>>>> A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash
>>>>>> works well, while mounting the SD card and doing an 'ls' produces
>>>>>> immediate BCH DMA timeouts.
>>>>>>
>>>>>> Perhaps someone can make anything out of that.
>>>>> I have checked and the function dma_irq_callback is never called
>>>>> during my tests. This means the DMA transfer does not even works once.
>>>>>
>>>>> Also no clue here ...
>>>> Aren't you getting some undervolt on the powerrail for example ? btw the
>>>> driver
>>>> looks a bit crappy to me, but let's believe it works ;-)
>>>>
>>>>>> Lothar Wa?mann
>>>>>> --
>>>>>> ___________________________________________________________
>>>>>>
>>>>>> Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
>>>>>> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
>>>>>> Gesch?ftsf?hrer: Matthias Kaussen
>>>>>> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>>>>>>
>>>>>> www.karo-electronics.de | info at karo-electronics.de
>>>>>> ___________________________________________________________
>>>>> _______________________________________________
>>>>> linux-arm-kernel mailing list
>>>>> linux-arm-kernel at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Koen Beel]

Hi,

On Tue, Aug 2, 2011 at 10:49 AM, Huang Shijie <b32955@freescale.com> wrote:
> Hi Koen:
>
> I tested the driver in mx23evk board, and I do not find the DMA-timeout
> error.

Strange.
>
> The following is my test environment:
> [0] Hardware:
> ? ? ? MX23EVK PCB REV C

I have the same hardware. But also on our own hardware (mx23, but
different dram and different nand) it's failing with the same output
as on the evk (see log file in previous mail).

> [1] SW:
> ? ?kernel:git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi
> ? ?.config: my_config , you can find it in my previous email.
> ? ?cmdline: console=ttyAMA0,115200 root=/dev/mmcblk0p1 rw rootwait
> gpmi_debug_init mtdparts=gpmi-nand:20m(boot),-(user)

I use that git and your config file. Only thing i have changed to the
config is to integrate the initramfs rootfs.
Would it be possible for you to test using rootfs in initramfs? Now
you are using the mmc card as rootfs which is on the dma engine and
bus.


>
> [2] test shell script:
> ================================
>
> echo 0x20 > /sys/module/gpmi_nand/parameters/gpmi_debug

As said, don't have that gpmi_debug sysfs entry. Sure you don't have
any other modification done which are not in that git branch?

> flash_eraseall /dev/mtd1
> ubiformat /dev/mtd1
> flash_eraseall /dev/mtd1
> ubiattach /dev/ubi_ctrl -m 1
> ubimkvol /dev/ubi0 -N test -m
> mount -t ubifs ubi0:test tmp
> bonnie++ -d tmp -u 0 -s 2 -r 1
> bonnie++ -d tmp -u 0 -s 2 -r 1
> bonnie++ -d tmp -u 0 -s 2 -r 1
> umount tmp
> ubidetach /dev/ubi_ctrl -m 1
>
> ================================
>
> [3] conclusion
> ? It runs well in my mx23 board, and no DMA-TIMEOUT occur.
> I think there is some conflict in your board.

Don't know what conflict I would have with my board. I just use the
board without anything (mmc, lcd, ...) attached to it.

>
> BTW:
> ? I split the MTD to 20M and (the rest size).
So do I.

> The flash_eraseall works well.
> If i do not split the MTD, the flash_eraseall will not work.
That's strange because I use flash_eraseall on my mtd1 which is 108 MB.
I don't know how you boot but my uboot is in mtd0, so don't use that
part to test

> I guest overflow occurs in some place.
>
> Best Regards
> Huang Shijie
>
>
>> On Tue, Aug 2, 2011 at 8:37 AM, Huang Shijie<b32955@freescale.com> ?wrote:
>>>
>>> Hi,
>>>>
>>>> Hi,
>>>>
>>>> Don't think it's a hardware issue. After all it is working on the
>>>> mx23evk using the Freescale BSP based on 2.6.35.3.
>>>
>>> I doubt the Freescale BSP has fix the conflict, while the community
>>> kernel
>>> does not
>>> fix it.
>>> Anyway, I will do more test on the mx23 board myself.
>>
>> Strange indeed. I suspect that the BSP used another way to mark bad
>> blocks.
>>
>>>
>>>
>>>> Now I tested using this kernel command line:
>>>> mtdparts=gpmi-nand:20m(boot),-(user) gpmi_debug_init
>>>> (So I removed the ubi rootfs stuff, see previous mails).
>>>>
>>>> Its booting fine now without complaining about dma timeouts.
>>>
>>> ok.
>>
>> That's mainly because the ubi stuff is not done at startup.
>>
>>>> Have tried flash_eraseall /dev/mtd1. Now it's complaining and thinking
>>>> all blocks are bad. So a "flash_erase: Skipping bad block at 1db00000"
>>>> message for every erase block.
>>>> Writing 1 to /sys/devices/platform/imx23-gpmi-nand/ignorebad, makes to
>>>
>>> This is a very dangerous interface.
>>
>> I know but it solved an issue here. Now flash_eraseall seems to be
>> working again without that ignorebad turned on (only finds one bad
>> erase blcok).
>> Again: I suspect that the BSP used another way to mark bad blocks.
>>
>>>> go a little further giving 'only one' error but I doubt it's working
>>>> at all. See attached log file.
>>>>
>>>> When the trying ubiformat /dev/mtd1 its stopping with a dma timeout.
>>>
>>> echo 0x20> ?/sys/devices/platform/imx23-gpmi-nand/gpmi_debug
>>>
>>> to show the GPMI register when the DMA timeout occurs.
>>
>> Don't have this sysfs interface here. I also don't see where it is
>> registered in the driver code.
>> Anyway I have hardcoded GPMI_DEBUG_CRAZY in gpmi_debug_setup.
>>
>> log file attached.
>>
>> Regards,
>> Koen
>>
>>>
>>> Best Regards
>>> Huang Shijie
>>>>
>>>> Every subsequent action (e.g. using ubiformat or flash_eraseall) using
>>>> that dma channel is failing.
>>>> I have put a printk in mxs-dma.c around line 387:
>>>>
>>>> ? ? if (mxs_chan->status == DMA_IN_PROGRESS&& ? ?!append)
>>>> ? ? {
>>>> ? ? ? ? pr_err("dma already in progess!\n");
>>>> ? ? ? ? return NULL;
>>>> ? ? }
>>>>
>>>> I see that printk also in the log file in attach. Seems like the
>>>> mxs-dma is failing at some point and for the rest of the time always
>>>> keeps it's status at DMA_IN_PROGRESS
>>>>
>>>> Any input or feedback is welcome.
>>>>
>>>> Regards,
>>>> Koen
>>>>
>>>>
>>>> On Sun, Jul 31, 2011 at 3:51 PM, Marek Vasut<marek.vasut@gmail.com>
>>>> ?wrote:
>>>>>
>>>>> On Friday, July 29, 2011 05:00:48 PM Koen Beel wrote:
>>>>>>
>>>>>> On Fri, Jul 29, 2011 at 2:41 PM, Lothar
>>>>>> Wa?mann<LW@karo-electronics.de>
>>>>>
>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Koen Beel writes:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Fri, Jul 29, 2011 at 9:20 AM, Lothar
>>>>>>>> Wa?mann<LW@karo-electronics.de>
>>>>>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Koen Beel writes:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I have test on mx23evk board. Still see the same issues.
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 27, 2011 at 3:53 AM, Huang
>>>>>>>>>> Shijie<b32955@freescale.com>
>>>>>
>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for your test.
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> It's not really working for me.
>>>>>>>>>>>> I've applied all gpmi-nand driver patches and the dma driver
>>>>>>>>>>>> patches.
>>>>>>>>>>>>
>>>>>>>>>>>> I have added following kernel parameters:
>>>>>>>>>>>> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
>>>>>>>>>>>> rootfstype=ubifs gpmi_debug_init
>>>>>>>>>>>>
>>>>>>>>>>>> During boot I get already get DMA timeout:
>>>>>>>>>>>> [ ? ?2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout,
>>>>>>>>>>>> last DMA
>>>>>>>>>>>>
>>>>>>>>>>>> :1
>>>>>>>>>>>>
>>>>>>>>>>>> [ ? ?3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
>>>>>>>>>>>> ...
>>>>>>>>>>>> (see log file in attach line 89)
>>>>>>>>>>
>>>>>>>>>> I still see this DMA timeout when booting.
>>>>>>>>>> What kernel parameters do you use? I still use same as above.
>>>>>>>>>
>>>>>>>>> Do you have an SD card in the system? I'm getting the same error
>>>>>>>>> when
>>>>>>>>> accessing an SD card. Without SD card I can use the flash without
>>>>>>>>> any
>>>>>>>>> errors.
>>>>>>>>
>>>>>>>> No SD card in the system. At least not on my mx23evk board.
>>>>>>>> My real target hardware has a SDIO wifi chip.
>>>>>>>>
>>>>>>>> Are you also testing on the mx23evk board? Really strange it is not
>>>>>>>> reproducible here then.
>>>>>>>> Anyone using mx23evk please give:
>>>>>>>> - revision number of board (I have tested on rev C1)
>>>>>>>> - kernel parameter used (see previous mail for mine)
>>>>>>>
>>>>>>> It's getting ever more strange. I only have problems with concurrent
>>>>>>> access to the flash and SD-card when I do file system based accessed
>>>>>>> to the SD card.
>>>>>>> A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash
>>>>>>> works well, while mounting the SD card and doing an 'ls' produces
>>>>>>> immediate BCH DMA timeouts.
>>>>>>>
>>>>>>> Perhaps someone can make anything out of that.
>>>>>>
>>>>>> I have checked and the function dma_irq_callback is never called
>>>>>> during my tests. This means the DMA transfer does not even works once.
>>>>>>
>>>>>> Also no clue here ...
>>>>>
>>>>> Aren't you getting some undervolt on the powerrail for example ? btw
>>>>> the
>>>>> driver
>>>>> looks a bit crappy to me, but let's believe it works ;-)
>>>>>
>>>>>>> Lothar Wa?mann
>>>>>>> --
>>>>>>> ___________________________________________________________
>>>>>>>
>>>>>>> Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
>>>>>>> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
>>>>>>> Gesch?ftsf?hrer: Matthias Kaussen
>>>>>>> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>>>>>>>
>>>>>>> www.karo-electronics.de | info at karo-electronics.de
>>>>>>> ___________________________________________________________
>>>>>>
>>>>>> _______________________________________________
>>>>>> linux-arm-kernel mailing list
>>>>>> linux-arm-kernel at lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Huang Shijie]

hi:
>
>> The following is my test environment:
>> [0] Hardware:
>>        MX23EVK PCB REV C
> I have the same hardware. But also on our own hardware (mx23, but
> different dram and different nand) it's failing with the same output
> as on the evk (see log file in previous mail).
I will check the schematic of mx23 tomorrow, and find what will cause 
conflict with GPMI.
>> [1] SW:
>>     kernel:git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi
>>     .config: my_config , you can find it in my previous email.
>>     cmdline: console=ttyAMA0,115200 root=/dev/mmcblk0p1 rw rootwait
>> gpmi_debug_init mtdparts=gpmi-nand:20m(boot),-(user)
> I use that git and your config file. Only thing i have changed to the
> config is to integrate the initramfs rootfs.
> Would it be possible for you to test using rootfs in initramfs? Now
could you tell me how can i test the rootfs in initramfs?
I have no idea about how to test it.


> you are using the mmc card as rootfs which is on the dma engine and
> bus.
>
>
>> [2] test shell script:
>> ================================
>>
>> echo 0x20>  /sys/module/gpmi_nand/parameters/gpmi_debug
> As said, don't have that gpmi_debug sysfs entry. Sure you don't have
> any other modification done which are not in that git branch?
The sysfs entry does exit.
Please check carefully.
The code in gpmi-nand.c defines it.


>> flash_eraseall /dev/mtd1
>> ubiformat /dev/mtd1
>> flash_eraseall /dev/mtd1
>> ubiattach /dev/ubi_ctrl -m 1
>> ubimkvol /dev/ubi0 -N test -m
>> mount -t ubifs ubi0:test tmp
>> bonnie++ -d tmp -u 0 -s 2 -r 1
>> bonnie++ -d tmp -u 0 -s 2 -r 1
>> bonnie++ -d tmp -u 0 -s 2 -r 1
>> umount tmp
>> ubidetach /dev/ubi_ctrl -m 1
>>
>> ================================
>>
>> [3] conclusion
>>    It runs well in my mx23 board, and no DMA-TIMEOUT occur.
>> I think there is some conflict in your board.
> Don't know what conflict I would have with my board. I just use the
> board without anything (mmc, lcd, ...) attached to it.
>
>> BTW:
>>    I split the MTD to 20M and (the rest size).
> So do I.
>
>> The flash_eraseall works well.
>> If i do not split the MTD, the flash_eraseall will not work.
> That's strange because I use flash_eraseall on my mtd1 which is 108 MB.
> I don't know how you boot but my uboot is in mtd0, so don't use that
I boot the kernel by the USB with sb_loader.

Best Regards
Huang Shijie

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Koen Beel]

Hi,

On Tue, Aug 2, 2011 at 12:37 PM, Huang Shijie <b32955@freescale.com> wrote:
> hi:
>>
>>> The following is my test environment:
>>> [0] Hardware:
>>> ? ? ? MX23EVK PCB REV C
>>
>> I have the same hardware. But also on our own hardware (mx23, but
>> different dram and different nand) it's failing with the same output
>> as on the evk (see log file in previous mail).
>
> I will check the schematic of mx23 tomorrow, and find what will cause
> conflict with GPMI.
>>>
>>> [1] SW:
>>> ? ?kernel:git://git.linaro.org/people/shawnguo/linux-2.6.git mxs-gpmi
>>> ? ?.config: my_config , you can find it in my previous email.
>>> ? ?cmdline: console=ttyAMA0,115200 root=/dev/mmcblk0p1 rw rootwait
>>> gpmi_debug_init mtdparts=gpmi-nand:20m(boot),-(user)
>>
>> I use that git and your config file. Only thing i have changed to the
>> config is to integrate the initramfs rootfs.
>> Would it be possible for you to test using rootfs in initramfs? Now
>
> could you tell me how can i test the rootfs in initramfs?
> I have no idea about how to test it.

Via the linux menuconfig:
- Check the option "General setup > Initial RAM filesystem and RAM
disk (initramfs/initrd) support"
- Fill in "General setup > Initramfs source file(s)" (e.g. the path to
a cpio archive of the rootfs, or just the directory containing the
extracted rootfs).

>
>
>> you are using the mmc card as rootfs which is on the dma engine and
>> bus.
>>
>>
>>> [2] test shell script:
>>> ================================
>>>
>>> echo 0x20> ?/sys/module/gpmi_nand/parameters/gpmi_debug
>>
>> As said, don't have that gpmi_debug sysfs entry. Sure you don't have
>> any other modification done which are not in that git branch?
>
> The sysfs entry does exit.
> Please check carefully.
> The code in gpmi-nand.c defines it.

Ok, I see the module_param entry at the beginning of gpmi-nand.c.
Must have overlooked it as in previous mail you mentioned the path was
/sys/devices/platform/imx23-gpmi-nand/gpmi_debug
But no problem, it's working now.

>
>
>>> flash_eraseall /dev/mtd1
>>> ubiformat /dev/mtd1
>>> flash_eraseall /dev/mtd1
>>> ubiattach /dev/ubi_ctrl -m 1
>>> ubimkvol /dev/ubi0 -N test -m
>>> mount -t ubifs ubi0:test tmp
>>> bonnie++ -d tmp -u 0 -s 2 -r 1
>>> bonnie++ -d tmp -u 0 -s 2 -r 1
>>> bonnie++ -d tmp -u 0 -s 2 -r 1
>>> umount tmp
>>> ubidetach /dev/ubi_ctrl -m 1
>>>
>>> ================================
>>>
>>> [3] conclusion
>>> ? It runs well in my mx23 board, and no DMA-TIMEOUT occur.
>>> I think there is some conflict in your board.
>>
>> Don't know what conflict I would have with my board. I just use the
>> board without anything (mmc, lcd, ...) attached to it.
>>
>>> BTW:
>>> ? I split the MTD to 20M and (the rest size).
>>
>> So do I.
>>
>>> The flash_eraseall works well.
>>> If i do not split the MTD, the flash_eraseall will not work.
>>
>> That's strange because I use flash_eraseall on my mtd1 which is 108 MB.
>> I don't know how you boot but my uboot is in mtd0, so don't use that
>
> I boot the kernel by the USB with sb_loader.
>
> Best Regards
> Huang Shijie
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Huang Shijie]

? 2011?07?29? 23:00, Koen Beel ??:
> On Fri, Jul 29, 2011 at 2:41 PM, Lothar Wa?mann<LW@karo-electronics.de>  wrote:
>> Hi,
>>
>> Koen Beel writes:
>>> Hi,
>>>
>>> On Fri, Jul 29, 2011 at 9:20 AM, Lothar Wa?mann<LW@karo-electronics.de>  wrote:
>>>> Hi,
>>>>
>>>> Koen Beel writes:
>>>>> Hi,
>>>>>
>>>>> I have test on mx23evk board. Still see the same issues.
>>>>>
>>>>> On Wed, Jul 27, 2011 at 3:53 AM, Huang Shijie<b32955@freescale.com>  wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Thanks for your test.
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> It's not really working for me.
>>>>>>> I've applied all gpmi-nand driver patches and the dma driver patches.
>>>>>>>
>>>>>>> I have added following kernel parameters:
>>>>>>> mtdparts=gpmi-nand:20m(boot),-(user) ubi.mtd=1 root=ubi0:rootfs0
>>>>>>> rootfstype=ubifs gpmi_debug_init
>>>>>>>
>>>>>>> During boot I get already get DMA timeout:
>>>>>>> [    2.560000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA
>>>>>>> :1
>>>>>>> [    3.560000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
>>>>>>> ...
>>>>>>> (see log file in attach line 89)
>>>>> I still see this DMA timeout when booting.
>>>>> What kernel parameters do you use? I still use same as above.
>>>>>
>>>> Do you have an SD card in the system? I'm getting the same error when
>>>> accessing an SD card. Without SD card I can use the flash without any
>>>> errors.
>>> No SD card in the system. At least not on my mx23evk board.
>>> My real target hardware has a SDIO wifi chip.
>>>
>>> Are you also testing on the mx23evk board? Really strange it is not
>>> reproducible here then.
>>> Anyone using mx23evk please give:
>>> - revision number of board (I have tested on rev C1)
>>> - kernel parameter used (see previous mail for mine)
>>>
>> It's getting ever more strange. I only have problems with concurrent
>> access to the flash and SD-card when I do file system based accessed
>> to the SD card.
>> A 'dd if=/dev/mmcblk0 of=/dev/null' while excessively using the flash
>> works well, while mounting the SD card and doing an 'ls' produces
>> immediate BCH DMA timeouts.
>>
>> Perhaps someone can make anything out of that.
> I have checked and the function dma_irq_callback is never called
> during my tests. This means the DMA transfer does not even works once.
If the GPMI do not work well, it will not toggle the DMA to work, so the 
DMA may timeout.



Huang Shijie
> Also no clue here ...
>
>>
>> Lothar Wa?mann
>> --
>> ___________________________________________________________
>>
>> Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
>> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
>> Gesch?ftsf?hrer: Matthias Kaussen
>> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>>
>> www.karo-electronics.de | info at karo-electronics.de
>> ___________________________________________________________
>>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Wolfram Sang]

> > Do you have an SD card in the system? I'm getting the same error when
> > accessing an SD card. Without SD card I can use the flash without any
> > errors.
> 
> No SD card in the system. At least not on my mx23evk board.
> My real target hardware has a SDIO wifi chip.

Removing the SD didn't help here as well. Koen, which bootloader do you
use?

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110803/2c19e95c/attachment.sig>

[PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28

[Koen Beel]

Hi,

On Wed, Aug 3, 2011 at 12:37 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
>> > Do you have an SD card in the system? I'm getting the same error when
>> > accessing an SD card. Without SD card I can use the flash without any
>> > errors.
>>
>> No SD card in the system. At least not on my mx23evk board.
>> My real target hardware has a SDIO wifi chip.
>
> Removing the SD didn't help here as well. Koen, which bootloader do you
> use?

i'm using uboot in nand flash.
(build an sb file containing power_prep, boot_prep and uboot en
flashed to nand using kobs-ng tool)

In my setup uboot loads a uImage from tftp. This uImage contains the
full rootfs as initramfs. So no need for mmc, nfs or nand.

If someone would like to try using my uImage for mx23evk, you can
download it here:
https://www.transferbigfiles.com/025d4f2a-38da-266a-66d1-1d7a05b1b938?rid=J3Qh9b7Vb1ORXFtzU589fw%3d%3d

Regards,
Koen


>
> --
> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | Wolfram Sang ? ? ? ? ? ? ? ?|
> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk45JNYACgkQD27XaX1/VRt1hACdFt1CQltiTWSwcoaNXsmJqkS0
> ycQAn3oPqxZYK/wmtd5S9Gh5dj+5YM73
> =jJs2
> -----END PGP SIGNATURE-----
>
>