* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-21 6:47 ` Huang Shijie
0 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-07-21 6:47 UTC (permalink / raw)
To: dedekind1
Cc: arnd, w.sang, Huang Shijie, linux-mtd, shijie8, linux-arm-kernel, LW
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
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-21 6:47 ` Huang Shijie
0 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-07-21 6:47 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 1/3] MTD : add the common code for GPMI-NAND controller driver
2011-07-21 6:47 ` Huang Shijie
@ 2011-07-21 6:47 ` Huang Shijie
-1 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-07-21 6:47 UTC (permalink / raw)
To: dedekind1
Cc: arnd, w.sang, Huang Shijie, linux-mtd, shijie8, linux-arm-kernel, LW
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
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH v8 1/3] MTD : add the common code for GPMI-NAND controller driver
@ 2011-07-21 6:47 ` Huang Shijie
0 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-07-21 6:47 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH v8 2/3] MTD : add helper functions library and header files for GPMI NAND driver
2011-07-21 6:47 ` Huang Shijie
@ 2011-07-21 6:47 ` Huang Shijie
-1 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-07-21 6:47 UTC (permalink / raw)
To: dedekind1
Cc: arnd, w.sang, Huang Shijie, linux-mtd, shijie8, linux-arm-kernel, LW
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
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH v8 2/3] MTD : add helper functions library and header files for GPMI NAND driver
@ 2011-07-21 6:47 ` Huang Shijie
0 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-07-21 6:47 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH v8 3/3] MTD : add GPMI-NAND driver in the config and Makefile
2011-07-21 6:47 ` Huang Shijie
@ 2011-07-21 6:47 ` Huang Shijie
-1 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-07-21 6:47 UTC (permalink / raw)
To: dedekind1
Cc: arnd, w.sang, Huang Shijie, linux-mtd, shijie8, linux-arm-kernel, LW
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
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH v8 3/3] MTD : add GPMI-NAND driver in the config and Makefile
@ 2011-07-21 6:47 ` Huang Shijie
0 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-07-21 6:47 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-21 6:47 ` Huang Shijie
@ 2011-07-21 21:50 ` Wolfram Sang
-1 siblings, 0 replies; 72+ messages in thread
From: Wolfram Sang @ 2011-07-21 21:50 UTC (permalink / raw)
To: Huang Shijie; +Cc: arnd, dedekind1, linux-mtd, shijie8, linux-arm-kernel, LW
[-- Attachment #1: Type: text/plain, Size: 1974 bytes --]
> 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/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-21 21:50 ` Wolfram Sang
0 siblings, 0 replies; 72+ messages in thread
From: Wolfram Sang @ 2011-07-21 21:50 UTC (permalink / raw)
To: linux-arm-kernel
> 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>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-21 21:50 ` Wolfram Sang
@ 2011-07-22 3:30 ` Huang Shijie
-1 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-07-22 3:30 UTC (permalink / raw)
To: Wolfram Sang; +Cc: arnd, dedekind1, linux-mtd, shijie8, linux-arm-kernel, LW
[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]
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
>
[-- Attachment #2: my_config --]
[-- Type: text/plain, Size: 34754 bytes --]
#
# Automatically generated make config: don't edit
# Linux/arm 3.0.0-rc2 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_HAVE_PWM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
# CONFIG_ARCH_USES_GETTIMEOFFSET is not set
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_KTIME_SCALAR=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
# CONFIG_ARM_PATCH_PHYS_VIRT is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_FHANDLE is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y
#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_SHOW=y
# CONFIG_SPARSE_IRQ is not set
#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CGROUPS is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_NET_NS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y
#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_PERF_COUNTERS is not set
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_PROFILING is not set
CONFIG_TRACEPOINTS=y
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_INTEGRITY=y
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
CONFIG_INLINE_SPIN_UNLOCK=y
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
CONFIG_INLINE_READ_UNLOCK=y
# CONFIG_INLINE_READ_UNLOCK_BH is not set
CONFIG_INLINE_READ_UNLOCK_IRQ=y
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
CONFIG_INLINE_WRITE_UNLOCK=y
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
# CONFIG_MUTEX_SPIN_ON_OWNER is not set
CONFIG_FREEZER=y
#
# System Type
#
CONFIG_MMU=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_VEXPRESS is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_BCMRING is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_CNS3XXX is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_MXC is not set
CONFIG_ARCH_MXS=y
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_LOKI is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_NUC93X is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_PNX4008 is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS4 is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_TCC_926 is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_U8500 is not set
# CONFIG_ARCH_NOMADIK is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_VT8500 is not set
# CONFIG_GPIO_PCA953X is not set
CONFIG_MXS_HAVE_AMBA_DUART=y
CONFIG_MXS_HAVE_PLATFORM_AUART=y
CONFIG_MXS_HAVE_PLATFORM_FEC=y
CONFIG_MXS_HAVE_PLATFORM_FLEXCAN=y
CONFIG_MXS_HAVE_PLATFORM_GPMI_NAND=y
CONFIG_MXS_HAVE_PLATFORM_MXS_I2C=y
CONFIG_MXS_HAVE_PLATFORM_MXS_MMC=y
CONFIG_MXS_HAVE_PLATFORM_MXS_PWM=y
CONFIG_MXS_HAVE_PLATFORM_MXSFB=y
CONFIG_MXS_OCOTP=y
CONFIG_SOC_IMX23=y
CONFIG_SOC_IMX28=y
#
# MXS platforms:
#
CONFIG_MACH_STMP378X_DEVB=y
CONFIG_MACH_MX23EVK=y
CONFIG_MACH_MX28EVK=y
CONFIG_MODULE_TX28=y
CONFIG_MACH_TX28=y
#
# System MMU
#
#
# Processor Type
#
CONFIG_CPU_ARM926T=y
CONFIG_CPU_32v5=y
CONFIG_CPU_ABRT_EV5TJ=y
CONFIG_CPU_PABRT_LEGACY=y
CONFIG_CPU_CACHE_VIVT=y
CONFIG_CPU_COPY_V4WB=y
CONFIG_CPU_TLB_V4WBI=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
CONFIG_CPU_USE_DOMAINS=y
#
# Processor Features
#
# CONFIG_ARM_THUMB is not set
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_WRITETHROUGH is not set
# CONFIG_CPU_CACHE_ROUND_ROBIN is not set
CONFIG_ARM_L1_CACHE_SHIFT=5
#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
# CONFIG_PCCARD is not set
#
# Kernel Features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
# CONFIG_HIGHMEM is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
# CONFIG_COMPACTION is not set
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
#
# Boot options
#
# CONFIG_USE_OF is not set
CONFIG_ZBOOT_ROM_TEXT=0
CONFIG_ZBOOT_ROM_BSS=0
CONFIG_CMDLINE=""
# CONFIG_XIP_KERNEL is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_AUTO_ZRELADDR=y
#
# CPU Power Management
#
# CONFIG_CPU_IDLE is not set
#
# Floating point emulation
#
#
# At least one emulation must be selected
#
CONFIG_FPE_NWFPE=y
# CONFIG_FPE_NWFPE_XP is not set
# CONFIG_FPE_FASTFPE is not set
# CONFIG_VFP is not set
#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set
#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_APM_EMULATION is not set
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_HAMRADIO is not set
CONFIG_CAN=m
CONFIG_CAN_RAW=m
CONFIG_CAN_BCM=m
#
# CAN Device Drivers
#
# CONFIG_CAN_VCAN is not set
# CONFIG_CAN_SLCAN is not set
CONFIG_CAN_DEV=m
# CONFIG_CAN_CALC_BITTIMING is not set
# CONFIG_CAN_MCP251X is not set
CONFIG_HAVE_CAN_FLEXCAN=y
CONFIG_CAN_FLEXCAN=m
# CONFIG_CAN_SJA1000 is not set
# CONFIG_CAN_C_CAN is not set
# CONFIG_CAN_SOFTING is not set
# CONFIG_CAN_DEBUG_DEVICES is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_WIRELESS is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_TESTS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
# CONFIG_MTD_BLKDEVS is not set
# CONFIG_MTD_BLOCK is not set
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set
#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PLATRAM is not set
#
# Self-contained MTD device drivers
#
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_M25P80 is not set
# CONFIG_MTD_SST25L is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set
#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
CONFIG_MTD_NAND_ECC=y
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
# CONFIG_MTD_NAND_ECC_BCH is not set
# CONFIG_MTD_SM_COMMON is not set
# CONFIG_MTD_NAND_MUSEUM_IDS is not set
# CONFIG_MTD_NAND_GPIO is not set
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_NANDSIM is not set
CONFIG_MTD_NAND_GPMI_NAND=y
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_ONENAND is not set
#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
# CONFIG_MTD_UBI_GLUEBI is not set
# CONFIG_MTD_UBI_DEBUG is not set
# CONFIG_PARPORT is not set
# CONFIG_BLK_DEV is not set
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_MISC_DEVICES is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set
#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_MII is not set
CONFIG_PHYLIB=y
#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM63XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
CONFIG_NET_ETHERNET=y
# CONFIG_AX88796 is not set
# CONFIG_SMC91X is not set
# CONFIG_DM9000 is not set
CONFIG_ENC28J60=y
# CONFIG_ENC28J60_WRITEVERIFY is not set
# CONFIG_ETHOC is not set
# CONFIG_SMC911X is not set
# CONFIG_SMSC911X is not set
# CONFIG_DNET is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
# CONFIG_B44 is not set
# CONFIG_KS8842 is not set
# CONFIG_KS8851 is not set
# CONFIG_KS8851_MLL is not set
CONFIG_FEC=y
# CONFIG_FTMAC100 is not set
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_WLAN is not set
#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
#
# CAIF transport drivers
#
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_ADS7846 is not set
# CONFIG_TOUCHSCREEN_AD7877 is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_CY8CTMG110 is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
# CONFIG_TOUCHSCREEN_EETI is not set
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC2005 is not set
CONFIG_TOUCHSCREEN_TSC2007=m
# CONFIG_TOUCHSCREEN_W90X900 is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
# CONFIG_DEVKMEM is not set
#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX3107 is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_SERIAL_MXS_AUART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_RAMOOPS is not set
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_COMPAT is not set
CONFIG_I2C_CHARDEV=m
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y
#
# I2C Hardware Bus support
#
#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE is not set
# CONFIG_I2C_GPIO is not set
CONFIG_I2C_MXS=m
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set
#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y
#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
CONFIG_SPI_BITBANG=m
CONFIG_SPI_GPIO=m
# CONFIG_SPI_OC_TINY is not set
# CONFIG_SPI_PL022 is not set
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_DESIGNWARE is not set
#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set
#
# PPS support
#
# CONFIG_PPS is not set
#
# PPS generators support
#
#
# PTP clock support
#
#
# Enable Device Drivers -> PPS to see the PTP clock options.
#
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y
#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_BASIC_MMIO is not set
# CONFIG_GPIO_IT8761E is not set
# CONFIG_GPIO_EXYNOS4 is not set
CONFIG_GPIO_MXS=y
# CONFIG_GPIO_PLAT_SAMSUNG is not set
# CONFIG_GPIO_S5PC100 is not set
# CONFIG_GPIO_S5PV210 is not set
# CONFIG_GPIO_PL061 is not set
#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_ADP5588 is not set
#
# PCI GPIO expanders:
#
#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MCP23S08 is not set
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_74X164 is not set
#
# AC97 GPIO expanders:
#
#
# MODULbus GPIO expanders:
#
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y
#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set
# CONFIG_MFD_SUPPORT is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set
#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=m
#
# Display hardware drivers
#
#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set
# CONFIG_HID_SUPPORT is not set
# CONFIG_USB_SUPPORT is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MMC_CLKGATE is not set
#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set
#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_ARMMMCI is not set
# CONFIG_MMC_SDHCI is not set
CONFIG_MMC_MXS=y
# CONFIG_MMC_SPI is not set
# CONFIG_MMC_DW is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
CONFIG_LEDS_GPIO_REGISTER=y
# CONFIG_NFC_DEVICES is not set
# CONFIG_ACCESSIBILITY is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set
#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=m
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set
#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_DS3234 is not set
# CONFIG_RTC_DRV_PCF2123 is not set
#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
#
# on-CPU RTC drivers
#
# CONFIG_RTC_DRV_PL030 is not set
# CONFIG_RTC_DRV_PL031 is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set
#
# DMA Devices
#
# CONFIG_AMBA_PL08X is not set
# CONFIG_DW_DMAC is not set
# CONFIG_TIMB_DMA is not set
CONFIG_MXS_DMA=y
CONFIG_DMA_ENGINE=y
#
# DMA Clients
#
# CONFIG_NET_DMA is not set
# CONFIG_ASYNC_TX_DMA is not set
# CONFIG_DMATEST is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_CLKSRC_MMIO=y
#
# File systems
#
# CONFIG_EXT2_FS is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
# CONFIG_DNOTIFY is not set
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y
#
# Caches
#
CONFIG_FSCACHE=m
CONFIG_FSCACHE_STATS=y
# CONFIG_FSCACHE_HISTOGRAM is not set
# CONFIG_FSCACHE_DEBUG is not set
# CONFIG_FSCACHE_OBJECT_LIST is not set
CONFIG_CACHEFILES=m
# CONFIG_CACHEFILES_DEBUG is not set
# CONFIG_CACHEFILES_HISTOGRAM is not set
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS2_FS is not set
CONFIG_UBIFS_FS=y
# CONFIG_UBIFS_FS_XATTR is not set
# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
# CONFIG_UBIFS_FS_DEBUG is not set
# CONFIG_LOGFS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFS_V4_1 is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
# CONFIG_NFS_USE_NEW_IDMAPPER is not set
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_NLS is not set
#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_LOCKUP_DETECTOR=y
# CONFIG_HARDLOCKUP_DETECTOR is not set
# CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_EVENT_POWER_TRACING_DEPRECATED=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
CONFIG_BLK_DEV_IO_TRACE=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_KSTRTOX is not set
CONFIG_STRICT_DEVMEM=y
CONFIG_ARM_UNWIND=y
CONFIG_DEBUG_USER=y
# CONFIG_DEBUG_LL is not set
# CONFIG_OC_ETM is not set
#
# Security options
#
CONFIG_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_HASH=m
CONFIG_CRYPTO_HASH2=m
# CONFIG_CRYPTO_MANAGER is not set
# CONFIG_CRYPTO_MANAGER2 is not set
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set
#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set
#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set
#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set
#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
#
# Ciphers
#
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
CONFIG_CRYPTO_LZO=y
#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_HW is not set
CONFIG_BINARY_PRINTF=y
#
# Library routines
#
CONFIG_BITREVERSE=y
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
CONFIG_CRC7=m
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y
# CONFIG_AVERAGE is not set
[-- Attachment #3: a.sh --]
[-- Type: application/x-sh, Size: 347 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-22 3:30 ` Huang Shijie
0 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-07-22 3:30 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-22 3:30 ` Huang Shijie
@ 2011-07-22 5:57 ` Shawn Guo
-1 siblings, 0 replies; 72+ messages in thread
From: Shawn Guo @ 2011-07-22 5:57 UTC (permalink / raw)
To: Huang Shijie
Cc: arnd, dedekind1, Wolfram Sang, linux-mtd, shijie8, linux-arm-kernel, LW
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
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-22 5:57 ` Shawn Guo
0 siblings, 0 replies; 72+ messages in thread
From: Shawn Guo @ 2011-07-22 5:57 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-22 5:57 ` Shawn Guo
@ 2011-07-22 8:07 ` Huang Shijie
-1 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-07-22 8:07 UTC (permalink / raw)
To: Shawn Guo
Cc: arnd, dedekind1, Wolfram Sang, linux-mtd, shijie8, linux-arm-kernel, LW
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.
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-22 8:07 ` Huang Shijie
0 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-07-22 8:07 UTC (permalink / raw)
To: linux-arm-kernel
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.
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-22 8:07 ` Huang Shijie
@ 2011-07-26 14:29 ` Koen Beel
-1 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-07-26 14:29 UTC (permalink / raw)
To: Huang Shijie
Cc: arnd, dedekind1, Wolfram Sang, linux-mtd, linux-arm-kernel,
shijie8, Shawn Guo, LW
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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-26 14:29 ` Koen Beel
0 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-07-26 14:29 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-26 14:29 ` Koen Beel
@ 2011-07-27 1:53 ` Huang Shijie
-1 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-07-27 1:53 UTC (permalink / raw)
To: Koen Beel
Cc: arnd, dedekind1, Wolfram Sang, linux-mtd, linux-arm-kernel,
shijie8, Shawn Guo, LW
[-- Attachment #1: Type: text/plain, Size: 4964 bytes --]
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@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
[-- Attachment #2: my_config --]
[-- Type: text/plain, Size: 34754 bytes --]
#
# Automatically generated make config: don't edit
# Linux/arm 3.0.0-rc2 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_HAVE_PWM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
# CONFIG_ARCH_USES_GETTIMEOFFSET is not set
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_KTIME_SCALAR=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
# CONFIG_ARM_PATCH_PHYS_VIRT is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_FHANDLE is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y
#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_SHOW=y
# CONFIG_SPARSE_IRQ is not set
#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CGROUPS is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_NET_NS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y
#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_PERF_COUNTERS is not set
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_PROFILING is not set
CONFIG_TRACEPOINTS=y
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_INTEGRITY=y
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
CONFIG_INLINE_SPIN_UNLOCK=y
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
CONFIG_INLINE_READ_UNLOCK=y
# CONFIG_INLINE_READ_UNLOCK_BH is not set
CONFIG_INLINE_READ_UNLOCK_IRQ=y
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
CONFIG_INLINE_WRITE_UNLOCK=y
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
# CONFIG_MUTEX_SPIN_ON_OWNER is not set
CONFIG_FREEZER=y
#
# System Type
#
CONFIG_MMU=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_VEXPRESS is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_BCMRING is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_CNS3XXX is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_MXC is not set
CONFIG_ARCH_MXS=y
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_LOKI is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_NUC93X is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_PNX4008 is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS4 is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_TCC_926 is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_U8500 is not set
# CONFIG_ARCH_NOMADIK is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_VT8500 is not set
# CONFIG_GPIO_PCA953X is not set
CONFIG_MXS_HAVE_AMBA_DUART=y
CONFIG_MXS_HAVE_PLATFORM_AUART=y
CONFIG_MXS_HAVE_PLATFORM_FEC=y
CONFIG_MXS_HAVE_PLATFORM_FLEXCAN=y
CONFIG_MXS_HAVE_PLATFORM_GPMI_NAND=y
CONFIG_MXS_HAVE_PLATFORM_MXS_I2C=y
CONFIG_MXS_HAVE_PLATFORM_MXS_MMC=y
CONFIG_MXS_HAVE_PLATFORM_MXS_PWM=y
CONFIG_MXS_HAVE_PLATFORM_MXSFB=y
CONFIG_MXS_OCOTP=y
CONFIG_SOC_IMX23=y
CONFIG_SOC_IMX28=y
#
# MXS platforms:
#
CONFIG_MACH_STMP378X_DEVB=y
CONFIG_MACH_MX23EVK=y
CONFIG_MACH_MX28EVK=y
CONFIG_MODULE_TX28=y
CONFIG_MACH_TX28=y
#
# System MMU
#
#
# Processor Type
#
CONFIG_CPU_ARM926T=y
CONFIG_CPU_32v5=y
CONFIG_CPU_ABRT_EV5TJ=y
CONFIG_CPU_PABRT_LEGACY=y
CONFIG_CPU_CACHE_VIVT=y
CONFIG_CPU_COPY_V4WB=y
CONFIG_CPU_TLB_V4WBI=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
CONFIG_CPU_USE_DOMAINS=y
#
# Processor Features
#
# CONFIG_ARM_THUMB is not set
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_WRITETHROUGH is not set
# CONFIG_CPU_CACHE_ROUND_ROBIN is not set
CONFIG_ARM_L1_CACHE_SHIFT=5
#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
# CONFIG_PCCARD is not set
#
# Kernel Features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
# CONFIG_HIGHMEM is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
# CONFIG_COMPACTION is not set
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
#
# Boot options
#
# CONFIG_USE_OF is not set
CONFIG_ZBOOT_ROM_TEXT=0
CONFIG_ZBOOT_ROM_BSS=0
CONFIG_CMDLINE=""
# CONFIG_XIP_KERNEL is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_AUTO_ZRELADDR=y
#
# CPU Power Management
#
# CONFIG_CPU_IDLE is not set
#
# Floating point emulation
#
#
# At least one emulation must be selected
#
CONFIG_FPE_NWFPE=y
# CONFIG_FPE_NWFPE_XP is not set
# CONFIG_FPE_FASTFPE is not set
# CONFIG_VFP is not set
#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set
#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_APM_EMULATION is not set
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_HAMRADIO is not set
CONFIG_CAN=m
CONFIG_CAN_RAW=m
CONFIG_CAN_BCM=m
#
# CAN Device Drivers
#
# CONFIG_CAN_VCAN is not set
# CONFIG_CAN_SLCAN is not set
CONFIG_CAN_DEV=m
# CONFIG_CAN_CALC_BITTIMING is not set
# CONFIG_CAN_MCP251X is not set
CONFIG_HAVE_CAN_FLEXCAN=y
CONFIG_CAN_FLEXCAN=m
# CONFIG_CAN_SJA1000 is not set
# CONFIG_CAN_C_CAN is not set
# CONFIG_CAN_SOFTING is not set
# CONFIG_CAN_DEBUG_DEVICES is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_WIRELESS is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_TESTS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
# CONFIG_MTD_BLKDEVS is not set
# CONFIG_MTD_BLOCK is not set
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set
#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PLATRAM is not set
#
# Self-contained MTD device drivers
#
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_M25P80 is not set
# CONFIG_MTD_SST25L is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set
#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
CONFIG_MTD_NAND_ECC=y
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
# CONFIG_MTD_NAND_ECC_BCH is not set
# CONFIG_MTD_SM_COMMON is not set
# CONFIG_MTD_NAND_MUSEUM_IDS is not set
# CONFIG_MTD_NAND_GPIO is not set
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_NANDSIM is not set
CONFIG_MTD_NAND_GPMI_NAND=y
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_ONENAND is not set
#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
# CONFIG_MTD_UBI_GLUEBI is not set
# CONFIG_MTD_UBI_DEBUG is not set
# CONFIG_PARPORT is not set
# CONFIG_BLK_DEV is not set
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_MISC_DEVICES is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set
#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_MII is not set
CONFIG_PHYLIB=y
#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM63XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
CONFIG_NET_ETHERNET=y
# CONFIG_AX88796 is not set
# CONFIG_SMC91X is not set
# CONFIG_DM9000 is not set
CONFIG_ENC28J60=y
# CONFIG_ENC28J60_WRITEVERIFY is not set
# CONFIG_ETHOC is not set
# CONFIG_SMC911X is not set
# CONFIG_SMSC911X is not set
# CONFIG_DNET is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
# CONFIG_B44 is not set
# CONFIG_KS8842 is not set
# CONFIG_KS8851 is not set
# CONFIG_KS8851_MLL is not set
CONFIG_FEC=y
# CONFIG_FTMAC100 is not set
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_WLAN is not set
#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
#
# CAIF transport drivers
#
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_ADS7846 is not set
# CONFIG_TOUCHSCREEN_AD7877 is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_CY8CTMG110 is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
# CONFIG_TOUCHSCREEN_EETI is not set
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC2005 is not set
CONFIG_TOUCHSCREEN_TSC2007=m
# CONFIG_TOUCHSCREEN_W90X900 is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
# CONFIG_DEVKMEM is not set
#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX3107 is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_SERIAL_MXS_AUART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_RAMOOPS is not set
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_COMPAT is not set
CONFIG_I2C_CHARDEV=m
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y
#
# I2C Hardware Bus support
#
#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE is not set
# CONFIG_I2C_GPIO is not set
CONFIG_I2C_MXS=m
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set
#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y
#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
CONFIG_SPI_BITBANG=m
CONFIG_SPI_GPIO=m
# CONFIG_SPI_OC_TINY is not set
# CONFIG_SPI_PL022 is not set
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_DESIGNWARE is not set
#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set
#
# PPS support
#
# CONFIG_PPS is not set
#
# PPS generators support
#
#
# PTP clock support
#
#
# Enable Device Drivers -> PPS to see the PTP clock options.
#
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y
#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_BASIC_MMIO is not set
# CONFIG_GPIO_IT8761E is not set
# CONFIG_GPIO_EXYNOS4 is not set
CONFIG_GPIO_MXS=y
# CONFIG_GPIO_PLAT_SAMSUNG is not set
# CONFIG_GPIO_S5PC100 is not set
# CONFIG_GPIO_S5PV210 is not set
# CONFIG_GPIO_PL061 is not set
#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_ADP5588 is not set
#
# PCI GPIO expanders:
#
#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MCP23S08 is not set
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_74X164 is not set
#
# AC97 GPIO expanders:
#
#
# MODULbus GPIO expanders:
#
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y
#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set
# CONFIG_MFD_SUPPORT is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set
#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=m
#
# Display hardware drivers
#
#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set
# CONFIG_HID_SUPPORT is not set
# CONFIG_USB_SUPPORT is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MMC_CLKGATE is not set
#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set
#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_ARMMMCI is not set
# CONFIG_MMC_SDHCI is not set
CONFIG_MMC_MXS=y
# CONFIG_MMC_SPI is not set
# CONFIG_MMC_DW is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
CONFIG_LEDS_GPIO_REGISTER=y
# CONFIG_NFC_DEVICES is not set
# CONFIG_ACCESSIBILITY is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set
#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=m
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set
#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_DS3234 is not set
# CONFIG_RTC_DRV_PCF2123 is not set
#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
#
# on-CPU RTC drivers
#
# CONFIG_RTC_DRV_PL030 is not set
# CONFIG_RTC_DRV_PL031 is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set
#
# DMA Devices
#
# CONFIG_AMBA_PL08X is not set
# CONFIG_DW_DMAC is not set
# CONFIG_TIMB_DMA is not set
CONFIG_MXS_DMA=y
CONFIG_DMA_ENGINE=y
#
# DMA Clients
#
# CONFIG_NET_DMA is not set
# CONFIG_ASYNC_TX_DMA is not set
# CONFIG_DMATEST is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_CLKSRC_MMIO=y
#
# File systems
#
# CONFIG_EXT2_FS is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
# CONFIG_DNOTIFY is not set
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y
#
# Caches
#
CONFIG_FSCACHE=m
CONFIG_FSCACHE_STATS=y
# CONFIG_FSCACHE_HISTOGRAM is not set
# CONFIG_FSCACHE_DEBUG is not set
# CONFIG_FSCACHE_OBJECT_LIST is not set
CONFIG_CACHEFILES=m
# CONFIG_CACHEFILES_DEBUG is not set
# CONFIG_CACHEFILES_HISTOGRAM is not set
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS2_FS is not set
CONFIG_UBIFS_FS=y
# CONFIG_UBIFS_FS_XATTR is not set
# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
# CONFIG_UBIFS_FS_DEBUG is not set
# CONFIG_LOGFS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFS_V4_1 is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
# CONFIG_NFS_USE_NEW_IDMAPPER is not set
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_NLS is not set
#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_LOCKUP_DETECTOR=y
# CONFIG_HARDLOCKUP_DETECTOR is not set
# CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_EVENT_POWER_TRACING_DEPRECATED=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
CONFIG_BLK_DEV_IO_TRACE=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_KSTRTOX is not set
CONFIG_STRICT_DEVMEM=y
CONFIG_ARM_UNWIND=y
CONFIG_DEBUG_USER=y
# CONFIG_DEBUG_LL is not set
# CONFIG_OC_ETM is not set
#
# Security options
#
CONFIG_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_HASH=m
CONFIG_CRYPTO_HASH2=m
# CONFIG_CRYPTO_MANAGER is not set
# CONFIG_CRYPTO_MANAGER2 is not set
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set
#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set
#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set
#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set
#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
#
# Ciphers
#
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
CONFIG_CRYPTO_LZO=y
#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_HW is not set
CONFIG_BINARY_PRINTF=y
#
# Library routines
#
CONFIG_BITREVERSE=y
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
CONFIG_CRC7=m
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y
# CONFIG_AVERAGE is not set
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-27 1:53 ` Huang Shijie
0 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-07-27 1:53 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-27 1:53 ` Huang Shijie
@ 2011-07-28 9:38 ` Koen Beel
-1 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-07-28 9:38 UTC (permalink / raw)
To: Huang Shijie
Cc: arnd, dedekind1, Wolfram Sang, linux-mtd, linux-arm-kernel,
shijie8, Shawn Guo, LW
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@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-28 9:38 ` Koen Beel
0 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-07-28 9:38 UTC (permalink / raw)
To: linux-arm-kernel
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
>>>
>
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-28 9:38 ` Koen Beel
@ 2011-07-29 7:20 ` Lothar Waßmann
-1 siblings, 0 replies; 72+ messages in thread
From: Lothar Waßmann @ 2011-07-29 7:20 UTC (permalink / raw)
To: Koen Beel
Cc: arnd, dedekind1, Wolfram Sang, Huang Shijie, linux-mtd,
linux-arm-kernel, shijie8, Shawn Guo
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@karo-electronics.de
___________________________________________________________
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-29 7:20 ` Lothar Waßmann
0 siblings, 0 replies; 72+ messages in thread
From: Lothar Waßmann @ 2011-07-29 7:20 UTC (permalink / raw)
To: linux-arm-kernel
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
___________________________________________________________
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-29 7:20 ` Lothar Waßmann
@ 2011-07-29 7:40 ` Koen Beel
-1 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-07-29 7:40 UTC (permalink / raw)
To: Lothar Waßmann
Cc: arnd, dedekind1, Wolfram Sang, Huang Shijie, linux-mtd,
linux-arm-kernel, shijie8, Shawn Guo
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@karo-electronics.de
> ___________________________________________________________
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-29 7:40 ` Koen Beel
0 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-07-29 7:40 UTC (permalink / raw)
To: linux-arm-kernel
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
> ___________________________________________________________
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-29 7:40 ` Koen Beel
@ 2011-07-29 7:49 ` Lothar Waßmann
-1 siblings, 0 replies; 72+ messages in thread
From: Lothar Waßmann @ 2011-07-29 7:49 UTC (permalink / raw)
To: Koen Beel
Cc: arnd, dedekind1, Wolfram Sang, Huang Shijie, linux-mtd,
linux-arm-kernel, shijie8, Shawn Guo
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@karo-electronics.de
___________________________________________________________
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-29 7:49 ` Lothar Waßmann
0 siblings, 0 replies; 72+ messages in thread
From: Lothar Waßmann @ 2011-07-29 7:49 UTC (permalink / raw)
To: linux-arm-kernel
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
___________________________________________________________
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-29 7:40 ` Koen Beel
@ 2011-07-29 9:49 ` Huang Shijie
-1 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-07-29 9:49 UTC (permalink / raw)
To: Koen Beel
Cc: arnd, dedekind1, Wolfram Sang, linux-mtd, linux-arm-kernel,
shijie8, Shawn Guo, Lothar Waßmann
于 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@karo-electronics.de
>> ___________________________________________________________
>>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-29 9:49 ` Huang Shijie
0 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-07-29 9:49 UTC (permalink / raw)
To: linux-arm-kernel
? 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
>> ___________________________________________________________
>>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-29 9:49 ` Huang Shijie
@ 2011-07-29 11:48 ` Koen Beel
-1 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-07-29 11:48 UTC (permalink / raw)
To: Huang Shijie
Cc: arnd, dedekind1, Wolfram Sang, linux-mtd, Shawn Guo, shijie8,
linux-arm-kernel, Lothar Waßmann
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@karo-electronics.de
>>> ___________________________________________________________
>>>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-29 11:48 ` Koen Beel
0 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-07-29 11:48 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-29 7:40 ` Koen Beel
@ 2011-07-29 12:41 ` Lothar Waßmann
-1 siblings, 0 replies; 72+ messages in thread
From: Lothar Waßmann @ 2011-07-29 12:41 UTC (permalink / raw)
To: Koen Beel
Cc: arnd, dedekind1, Wolfram Sang, Huang Shijie, linux-mtd,
linux-arm-kernel, shijie8, Shawn Guo
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@karo-electronics.de
___________________________________________________________
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-29 12:41 ` Lothar Waßmann
0 siblings, 0 replies; 72+ messages in thread
From: Lothar Waßmann @ 2011-07-29 12:41 UTC (permalink / raw)
To: linux-arm-kernel
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
___________________________________________________________
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-29 12:41 ` Lothar Waßmann
@ 2011-07-29 15:00 ` Koen Beel
-1 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-07-29 15:00 UTC (permalink / raw)
To: Lothar Waßmann
Cc: arnd, dedekind1, Wolfram Sang, Huang Shijie, linux-mtd,
linux-arm-kernel, shijie8, Shawn Guo
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@karo-electronics.de
> ___________________________________________________________
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-29 15:00 ` Koen Beel
0 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-07-29 15:00 UTC (permalink / raw)
To: linux-arm-kernel
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
> ___________________________________________________________
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-29 15:00 ` Koen Beel
@ 2011-07-31 13:51 ` Marek Vasut
-1 siblings, 0 replies; 72+ messages in thread
From: Marek Vasut @ 2011-07-31 13:51 UTC (permalink / raw)
To: linux-arm-kernel
Cc: arnd, dedekind1, Koen Beel, Wolfram Sang, Huang Shijie,
linux-mtd, shijie8, Shawn Guo, Lothar Waßmann
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@karo-electronics.de
> > ___________________________________________________________
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-07-31 13:51 ` Marek Vasut
0 siblings, 0 replies; 72+ messages in thread
From: Marek Vasut @ 2011-07-31 13:51 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-31 13:51 ` Marek Vasut
@ 2011-08-01 15:14 ` Koen Beel
-1 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-08-01 15:14 UTC (permalink / raw)
To: Marek Vasut
Cc: arnd, dedekind1, Wolfram Sang, Huang Shijie, linux-mtd,
Shawn Guo, shijie8, linux-arm-kernel, Lothar Waßmann
[-- Attachment #1: Type: text/plain, Size: 4823 bytes --]
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@karo-electronics.de
>> > ___________________________________________________________
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
[-- Attachment #2: log1 --]
[-- Type: application/octet-stream, Size: 2645 bytes --]
# flash_eraseall /dev/mtd1
flash_eraseall has been replaced by `flash_erase <mtddev> 0 0`; please use it
Erasing 512 Kibyte @ 5c80000 -- 2 % complete libmtd: error!: MEMERASE64 ioctl failed for eraseblock 185 (mtd1)
error 5 (Input/output error)
flash_erase: error!: /dev/mtd1: MTD Erase failure
error 5 (Input/output error)
Erasing 512 Kibyte @ feb80000 -- 100 % complete
# ubiformat /dev/mtd1
ubiformat: mtd1 (nand), size 4273995776 bytes (4.0 GiB), 8152 eraseblocks of 524288 bytes (512.0 KiB), min. I/O size 4096 bytes
libscan: scanning eraseblock 0 -- 0 % complete [ 222.730000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA :1
[ 223.730000] [ start_dma_with_bch_irq : 427 ] bch timeout!!!
[ 223.730000] [ mil_ecc_read_page : 1054 ] Error in ECC-based read: -110
libmtd: error!: cannot read 64 bytes from mtd1 (eraseblock 0, offset 0)
error 110 (Connection timed out)
ubiformat: error!: failed to scan mtd1 (/dev/mtd1)
#
#
# ubiformat /dev/mtd1
ubiformat: mtd1 (nand), [ 229.490000] dma already in progess!
size 4273995776 bytes (4.0 GiB),[ 229.500000] [ gpmi_send_command : 749 ] step 1 error
8152 eraseblocks of 524288 bytes (512.0 KiB), min. I/O size 4096 bytes
libscan: scanning eraseblock 0 -- 0 % complete [ 229.520000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
[ 229.520000] dma already in progess!
[ 229.520000] [ gpmi_send_command : 749 ] step 1 error
[ 229.530000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
[ 229.540000] dma already in progess!
[ 229.540000] [ gpmi_read_page : 924 ] step 1 error
[ 229.540000] [ mil_ecc_read_page : 1054 ] Error in ECC-based read: -1
libmtd: error!: cannot read 64 bytes from mtd1 (eraseblock 0, offset 0)
error 1 (Operation not permitted)
ubiformat: error!: failed to scan mtd1 (/dev/mtd1)
#
#
# ubiformat /dev/mtd1
ubiformat: mtd1 (nand), [ 237.360000] dma already in progess!
size 4273995776 bytes (4.0 GiB),[ 237.370000] [ gpmi_send_command : 749 ] step 1 error
8152 eraseblocks of 524288 bytes (512.0 KiB), min. I/O size 4096 bytes
libscan: scanning eraseblock 0 -- 0 % complete [ 237.390000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
[ 237.390000] dma already in progess!
[ 237.400000] [ gpmi_send_command : 749 ] step 1 error
[ 237.400000] [ mil_cmd_ctrl : 894 ] Chip: 0, Error -1
[ 237.410000] dma already in progess!
[ 237.410000] [ gpmi_read_page : 924 ] step 1 error
[ 237.420000] [ mil_ecc_read_page : 1054 ] Error in ECC-based read: -1
libmtd: error!: cannot read 64 bytes from mtd1 (eraseblock 0, offset 0)
error 1 (Operation not permitted)
ubiformat: error!: failed to scan mtd1 (/dev/mtd1)
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-01 15:14 ` Koen Beel
0 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-08-01 15:14 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-29 11:48 ` Koen Beel
@ 2011-08-02 6:19 ` Huang Shijie
-1 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-08-02 6:19 UTC (permalink / raw)
To: Koen Beel
Cc: arnd, dedekind1, Wolfram Sang, linux-mtd, Shawn Guo, shijie8,
linux-arm-kernel, Lothar Waßmann
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@karo-electronics.de
>>>> ___________________________________________________________
>>>>
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-02 6:19 ` Huang Shijie
0 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-08-02 6:19 UTC (permalink / raw)
To: linux-arm-kernel
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
>>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-29 15:00 ` Koen Beel
@ 2011-08-02 6:21 ` Huang Shijie
-1 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-08-02 6:21 UTC (permalink / raw)
To: Koen Beel
Cc: arnd, dedekind1, Wolfram Sang, linux-mtd, linux-arm-kernel,
shijie8, Shawn Guo, Lothar Waßmann
于 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@karo-electronics.de
>> ___________________________________________________________
>>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-02 6:21 ` Huang Shijie
0 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-08-02 6:21 UTC (permalink / raw)
To: linux-arm-kernel
? 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
>> ___________________________________________________________
>>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-08-01 15:14 ` Koen Beel
@ 2011-08-02 6:37 ` Huang Shijie
-1 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-08-02 6:37 UTC (permalink / raw)
To: Koen Beel
Cc: arnd, dedekind1, Wolfram Sang, Marek Vasut, linux-mtd, Shawn Guo,
shijie8, linux-arm-kernel, Lothar Waßmann
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@karo-electronics.de
>>>> ___________________________________________________________
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-02 6:37 ` Huang Shijie
0 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-08-02 6:37 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-08-02 6:19 ` Huang Shijie
@ 2011-08-02 7:16 ` Shawn Guo
-1 siblings, 0 replies; 72+ messages in thread
From: Shawn Guo @ 2011-08-02 7:16 UTC (permalink / raw)
To: Huang Shijie
Cc: arnd, dedekind1, Koen Beel, Wolfram Sang, linux-mtd, shijie8,
linux-arm-kernel, Lothar Waßmann
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
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-02 7:16 ` Shawn Guo
0 siblings, 0 replies; 72+ messages in thread
From: Shawn Guo @ 2011-08-02 7:16 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-08-02 6:37 ` Huang Shijie
@ 2011-08-02 7:33 ` Koen Beel
-1 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-08-02 7:33 UTC (permalink / raw)
To: Huang Shijie
Cc: arnd, dedekind1, Wolfram Sang, Marek Vasut, linux-mtd, Shawn Guo,
shijie8, linux-arm-kernel, Lothar Waßmann
[-- Attachment #1: Type: text/plain, Size: 6148 bytes --]
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@karo-electronics.de
>>>>> ___________________________________________________________
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> linux-arm-kernel@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
[-- Attachment #2: log2 --]
[-- Type: application/octet-stream, Size: 2897 bytes --]
# flash_eraseall /dev/mtd1
flash_eraseall has been replaced by `flash_erase <mtddev> 0 0`; please use it
Erasing 512 Kibyte @ 5c00000 -- 2 % complete flash_erase: Skipping bad block at 05c80000
Erasing 512 Kibyte @ feb80000 -- 100 % complete
#
#
#
# ubiformat /dev/mtd0
ubiformat: mtd0 (nand), size 20971520 bytes (20.0 MiB), 40 eraseblocks of 524288 bytes (512.0 KiB), min. I/O size 4096 bytes
libscan: scanning eraseblock 0 -- 2 % complete [ 449.760000] [ start_dma_without_bch_irq : 392 ] DMA timeout, last DMA :1
[ 449.760000] [ gpmi_show_regs : 076 ] -------------- Show GPMI registers ----------
[ 449.770000] [ gpmi_show_regs : 079 ] offset 0x000 : 0x238010da
[ 449.780000] [ gpmi_show_regs : 079 ] offset 0x010 : 0x00000000
[ 449.780000] [ gpmi_show_regs : 079 ] offset 0x020 : 0x000011ff
[ 449.790000] [ gpmi_show_regs : 079 ] offset 0x030 : 0x000010da
[ 449.800000] [ gpmi_show_regs : 079 ] offset 0x040 : 0x40da4480
[ 449.800000] [ gpmi_show_regs : 079 ] offset 0x050 : 0x40d95000
[ 449.810000] [ gpmi_show_regs : 079 ] offset 0x060 : 0x0004000c
[ 449.820000] [ gpmi_show_regs : 079 ] offset 0x070 : 0x00010203
[ 449.820000] [ gpmi_show_regs : 079 ] offset 0x080 : 0x05000000
[ 449.830000] [ gpmi_show_regs : 079 ] offset 0x090 : 0x09020101
[ 449.840000] [ gpmi_show_regs : 079 ] offset 0x0a0 : 0x00000030
[ 449.840000] [ gpmi_show_regs : 079 ] offset 0x0b0 : 0x80000010
[ 449.850000] [ gpmi_show_regs : 079 ] offset 0x0c0 : 0x100000ba
[ 449.860000] [ gpmi_show_regs : 079 ] offset 0x0d0 : 0x03000000
[ 449.860000] [ gpmi_show_regs : 081 ] -------------- Show GPMI registers end ----------
[ 449.870000] Kernel panic - not syncing: -----------DMA FAILED------------------
[ 449.880000] [<c033b9b0>] (unwind_backtrace+0x0/0xf0) from [<c05cfacc>] (panic+0x58/0x18c)
[ 449.890000] [<c05cfacc>] (panic+0x58/0x18c) from [<c0518ac4>] (start_dma_without_bch_irq+0x98/0xac)
[ 449.900000] [<c0518ac4>] (start_dma_without_bch_irq+0x98/0xac) from [<c0518b04>] (start_dma_with_bch_irq+0x2c/0x78)
[ 449.910000] [<c0518b04>] (start_dma_with_bch_irq+0x2c/0x78) from [<c051975c>] (gpmi_read_page+0x160/0x1cc)
[ 449.920000] [<c051975c>] (gpmi_read_page+0x160/0x1cc) from [<c051822c>] (mil_ecc_read_page+0x64/0x1dc)
[ 449.930000] [<c051822c>] (mil_ecc_read_page+0x64/0x1dc) from [<c051348c>] (nand_do_read_ops+0x1d8/0x468)
[ 449.940000] [<c051348c>] (nand_do_read_ops+0x1d8/0x468) from [<c0513a90>] (nand_read+0x94/0xb0)
[ 449.950000] [<c0513a90>] (nand_read+0x94/0xb0) from [<c050d654>] (part_read+0x60/0xe4)
[ 449.960000] [<c050d654>] (part_read+0x60/0xe4) from [<c050f0dc>] (mtd_read+0xd8/0x20c)
[ 449.970000] [<c050f0dc>] (mtd_read+0xd8/0x20c) from [<c03dc890>] (vfs_read+0xb0/0x180)
[ 449.970000] [<c03dc890>] (vfs_read+0xb0/0x180) from [<c03dc9a0>] (sys_read+0x40/0x70)
[ 449.980000] [<c03dc9a0>] (sys_read+0x40/0x70) from [<c0336780>] (ret_fast_syscall+0x0/0x2c)
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-02 7:33 ` Koen Beel
0 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-08-02 7:33 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-08-02 7:33 ` Koen Beel
@ 2011-08-02 7:44 ` Huang Shijie
-1 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-08-02 7:44 UTC (permalink / raw)
To: Koen Beel
Cc: arnd, dedekind1, Wolfram Sang, Marek Vasut, linux-mtd, Shawn Guo,
shijie8, linux-arm-kernel, Lothar Waßmann
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@karo-electronics.de
>>>>>> ___________________________________________________________
>>>>> _______________________________________________
>>>>> linux-arm-kernel mailing list
>>>>> linux-arm-kernel@lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-02 7:44 ` Huang Shijie
0 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-08-02 7:44 UTC (permalink / raw)
To: linux-arm-kernel
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
>>
>>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-08-02 6:19 ` Huang Shijie
@ 2011-08-02 8:11 ` Shawn Guo
-1 siblings, 0 replies; 72+ messages in thread
From: Shawn Guo @ 2011-08-02 8:11 UTC (permalink / raw)
To: Huang Shijie
Cc: arnd, dedekind1, Koen Beel, Wolfram Sang, linux-mtd, shijie8,
linux-arm-kernel, Lothar Waßmann
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
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-02 8:11 ` Shawn Guo
0 siblings, 0 replies; 72+ messages in thread
From: Shawn Guo @ 2011-08-02 8:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-08-02 6:19 ` Huang Shijie
@ 2011-08-02 8:12 ` Shawn Guo
-1 siblings, 0 replies; 72+ messages in thread
From: Shawn Guo @ 2011-08-02 8:12 UTC (permalink / raw)
To: Huang Shijie
Cc: arnd, dedekind1, Koen Beel, Wolfram Sang, linux-mtd, shijie8,
linux-arm-kernel, Lothar Waßmann
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
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-02 8:12 ` Shawn Guo
0 siblings, 0 replies; 72+ messages in thread
From: Shawn Guo @ 2011-08-02 8:12 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-08-02 8:12 ` Shawn Guo
@ 2011-08-02 8:22 ` Huang Shijie
-1 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-08-02 8:22 UTC (permalink / raw)
To: Shawn Guo
Cc: arnd, dedekind1, Koen Beel, Wolfram Sang, linux-mtd, shijie8,
linux-arm-kernel, Lothar Waßmann
于 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
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-02 8:22 ` Huang Shijie
0 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-08-02 8:22 UTC (permalink / raw)
To: linux-arm-kernel
? 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
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-08-02 7:33 ` Koen Beel
@ 2011-08-02 8:49 ` Huang Shijie
-1 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-08-02 8:49 UTC (permalink / raw)
To: Koen Beel
Cc: arnd, dedekind1, Wolfram Sang, Marek Vasut, linux-mtd, Shawn Guo,
shijie8, linux-arm-kernel, Lothar Waßmann
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@karo-electronics.de
>>>>>> ___________________________________________________________
>>>>> _______________________________________________
>>>>> linux-arm-kernel mailing list
>>>>> linux-arm-kernel@lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-02 8:49 ` Huang Shijie
0 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-08-02 8:49 UTC (permalink / raw)
To: linux-arm-kernel
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
>>
>>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-08-02 7:44 ` Huang Shijie
@ 2011-08-02 8:55 ` Koen Beel
-1 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-08-02 8:55 UTC (permalink / raw)
To: Huang Shijie
Cc: arnd, dedekind1, Wolfram Sang, Marek Vasut, linux-mtd, Shawn Guo,
shijie8, linux-arm-kernel, Lothar Waßmann
[-- Attachment #1: Type: text/plain, Size: 7895 bytes --]
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@karo-electronics.de
>>>>>>> ___________________________________________________________
>>>>>>
>>>>>> _______________________________________________
>>>>>> linux-arm-kernel mailing list
>>>>>> linux-arm-kernel@lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>>
>
>
>
[-- Attachment #2: flash_eraseall --]
[-- Type: application/octet-stream, Size: 150 bytes --]
#!/bin/sh
echo "${0##*/} has been replaced by \`flash_erase <mtddev> 0 0\`; please use it" 1>&2
[ $# -ne 0 ] && set -- "$@" 0 0
exec flash_erase "$@"
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-02 8:55 ` Koen Beel
0 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-08-02 8:55 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-08-02 8:49 ` Huang Shijie
@ 2011-08-02 9:29 ` Koen Beel
-1 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-08-02 9:29 UTC (permalink / raw)
To: Huang Shijie
Cc: arnd, dedekind1, Wolfram Sang, Marek Vasut, linux-mtd,
linux-arm-kernel, shijie8, Shawn Guo, Lothar Waßmann
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@karo-electronics.de
>>>>>>> ___________________________________________________________
>>>>>>
>>>>>> _______________________________________________
>>>>>> linux-arm-kernel mailing list
>>>>>> linux-arm-kernel@lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-02 9:29 ` Koen Beel
0 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-08-02 9:29 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-08-02 9:29 ` Koen Beel
@ 2011-08-02 10:37 ` Huang Shijie
-1 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-08-02 10:37 UTC (permalink / raw)
To: Koen Beel
Cc: arnd, dedekind1, Wolfram Sang, Marek Vasut, linux-mtd,
linux-arm-kernel, shijie8, Shawn Guo, Lothar Waßmann
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
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-02 10:37 ` Huang Shijie
0 siblings, 0 replies; 72+ messages in thread
From: Huang Shijie @ 2011-08-02 10:37 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-08-02 10:37 ` Huang Shijie
@ 2011-08-02 12:32 ` Koen Beel
-1 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-08-02 12:32 UTC (permalink / raw)
To: Huang Shijie
Cc: arnd, dedekind1, Wolfram Sang, Marek Vasut, linux-mtd, Shawn Guo,
shijie8, linux-arm-kernel, Lothar Waßmann
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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-02 12:32 ` Koen Beel
0 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-08-02 12:32 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-07-29 7:40 ` Koen Beel
@ 2011-08-03 10:37 ` Wolfram Sang
-1 siblings, 0 replies; 72+ messages in thread
From: Wolfram Sang @ 2011-08-03 10:37 UTC (permalink / raw)
To: Koen Beel
Cc: arnd, dedekind1, Huang Shijie, linux-mtd, linux-arm-kernel,
shijie8, Shawn Guo, Lothar Waßmann
[-- Attachment #1: Type: text/plain, Size: 519 bytes --]
> > 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/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-03 10:37 ` Wolfram Sang
0 siblings, 0 replies; 72+ messages in thread
From: Wolfram Sang @ 2011-08-03 10:37 UTC (permalink / raw)
To: linux-arm-kernel
> > 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>
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
2011-08-03 10:37 ` Wolfram Sang
@ 2011-08-03 12:00 ` Koen Beel
-1 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-08-03 12:00 UTC (permalink / raw)
To: Wolfram Sang
Cc: arnd, dedekind1, Huang Shijie, linux-mtd, linux-arm-kernel,
shijie8, Shawn Guo, Lothar Waßmann
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-----
>
>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28
@ 2011-08-03 12:00 ` Koen Beel
0 siblings, 0 replies; 72+ messages in thread
From: Koen Beel @ 2011-08-03 12:00 UTC (permalink / raw)
To: linux-arm-kernel
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-----
>
>
^ permalink raw reply [flat|nested] 72+ messages in thread
end of thread, other threads:[~2011-08-03 12:00 UTC | newest]
Thread overview: 72+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-21 6:47 [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28 Huang Shijie
2011-07-21 6:47 ` Huang Shijie
2011-07-21 6:47 ` [PATCH v8 1/3] MTD : add the common code for GPMI-NAND controller driver Huang Shijie
2011-07-21 6:47 ` Huang Shijie
2011-07-21 6:47 ` [PATCH v8 2/3] MTD : add helper functions library and header files for GPMI NAND driver Huang Shijie
2011-07-21 6:47 ` Huang Shijie
2011-07-21 6:47 ` [PATCH v8 3/3] MTD : add GPMI-NAND driver in the config and Makefile Huang Shijie
2011-07-21 6:47 ` Huang Shijie
2011-07-21 21:50 ` [PATCH v8 0/3] add the GPMI controller driver for IMX23/IMX28 Wolfram Sang
2011-07-21 21:50 ` Wolfram Sang
2011-07-22 3:30 ` Huang Shijie
2011-07-22 3:30 ` Huang Shijie
2011-07-22 5:57 ` Shawn Guo
2011-07-22 5:57 ` Shawn Guo
2011-07-22 8:07 ` Huang Shijie
2011-07-22 8:07 ` Huang Shijie
2011-07-26 14:29 ` Koen Beel
2011-07-26 14:29 ` Koen Beel
2011-07-27 1:53 ` Huang Shijie
2011-07-27 1:53 ` Huang Shijie
2011-07-28 9:38 ` Koen Beel
2011-07-28 9:38 ` Koen Beel
2011-07-29 7:20 ` Lothar Waßmann
2011-07-29 7:20 ` Lothar Waßmann
2011-07-29 7:40 ` Koen Beel
2011-07-29 7:40 ` Koen Beel
2011-07-29 7:49 ` Lothar Waßmann
2011-07-29 7:49 ` Lothar Waßmann
2011-07-29 9:49 ` Huang Shijie
2011-07-29 9:49 ` Huang Shijie
2011-07-29 11:48 ` Koen Beel
2011-07-29 11:48 ` Koen Beel
2011-08-02 6:19 ` Huang Shijie
2011-08-02 6:19 ` Huang Shijie
2011-08-02 7:16 ` Shawn Guo
2011-08-02 7:16 ` Shawn Guo
2011-08-02 8:11 ` Shawn Guo
2011-08-02 8:11 ` Shawn Guo
2011-08-02 8:12 ` Shawn Guo
2011-08-02 8:12 ` Shawn Guo
2011-08-02 8:22 ` Huang Shijie
2011-08-02 8:22 ` Huang Shijie
2011-07-29 12:41 ` Lothar Waßmann
2011-07-29 12:41 ` Lothar Waßmann
2011-07-29 15:00 ` Koen Beel
2011-07-29 15:00 ` Koen Beel
2011-07-31 13:51 ` Marek Vasut
2011-07-31 13:51 ` Marek Vasut
2011-08-01 15:14 ` Koen Beel
2011-08-01 15:14 ` Koen Beel
2011-08-02 6:37 ` Huang Shijie
2011-08-02 6:37 ` Huang Shijie
2011-08-02 7:33 ` Koen Beel
2011-08-02 7:33 ` Koen Beel
2011-08-02 7:44 ` Huang Shijie
2011-08-02 7:44 ` Huang Shijie
2011-08-02 8:55 ` Koen Beel
2011-08-02 8:55 ` Koen Beel
2011-08-02 8:49 ` Huang Shijie
2011-08-02 8:49 ` Huang Shijie
2011-08-02 9:29 ` Koen Beel
2011-08-02 9:29 ` Koen Beel
2011-08-02 10:37 ` Huang Shijie
2011-08-02 10:37 ` Huang Shijie
2011-08-02 12:32 ` Koen Beel
2011-08-02 12:32 ` Koen Beel
2011-08-02 6:21 ` Huang Shijie
2011-08-02 6:21 ` Huang Shijie
2011-08-03 10:37 ` Wolfram Sang
2011-08-03 10:37 ` Wolfram Sang
2011-08-03 12:00 ` Koen Beel
2011-08-03 12:00 ` Koen Beel
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.