From mboxrd@z Thu Jan 1 00:00:00 1970 From: LiuShuo Date: Fri, 9 Dec 2011 17:32:12 +0800 Subject: [U-Boot] [PATCH 5/5] mtd/nand: workaround for Freescale FCM to support 4k pagesize Nand chip In-Reply-To: <201112091011.30256.marek.vasut@gmail.com> References: <1323341352-14996-1-git-send-email-Shengzhou.Liu@freescale.com> <201112090927.51821.marek.vasut@gmail.com> <4EE1CDB2.6010102@freescale.com> <201112091011.30256.marek.vasut@gmail.com> Message-ID: <4EE1D59C.6020906@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de ? 2011?12?09? 17:11, Marek Vasut ??: >> ? 2011?12?09? 16:27, Marek Vasut ??: >>>> ? 2011?12?09? 00:37, Marek Vasut ??: >>>>>> Freescale FCM controller has a 2K size limitation of buffer RAM. In >>>>>> order to support the Nand flash chip whose page size is larger than 2K >>>>>> bytes, we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB >>>>>> and save them to a large buffer. >>>>>> >>>>>> Signed-off-by: Shengzhou Liu >>>>>> Signed-off-by: Liu Shuo >>>>>> --- >>>>>> >>>>>> drivers/mtd/nand/fsl_elbc_nand.c | 279 >>>>>> >>>>>> +++++++++++++++++++++++++++++++++---- 1 files changed, 248 >>>>>> insertions(+), 31 deletions(-) >>>>>> >>>>>> diff --git a/drivers/mtd/nand/fsl_elbc_nand.c >>>>>> b/drivers/mtd/nand/fsl_elbc_nand.c index 52362b1..3983c8c 100644 >>>>>> --- a/drivers/mtd/nand/fsl_elbc_nand.c >>>>>> +++ b/drivers/mtd/nand/fsl_elbc_nand.c >>>>>> @@ -64,7 +64,6 @@ struct fsl_elbc_mtd { >>>>>> >>>>>> struct device *dev; >>>>>> int bank; /* Chip select bank number */ >>>>>> u8 __iomem *vbase; /* Chip select base virtual address */ >>>>>> >>>>>> - int page_size; /* NAND page size (0=512, 1=2048) */ >>>>>> >>>>>> unsigned int fmr; /* FCM Flash Mode Register value */ >>>>>> >>>>>> }; >>>>>> >>>>>> @@ -85,6 +84,8 @@ struct fsl_elbc_ctrl { >>>>>> >>>>>> unsigned int mdr; /* UPM/FCM Data Register value >>>>>> */ unsigned int use_mdr; /* Non zero if the MDR is to be set >>>>>> */ unsigned int oob; /* Non zero if operating on OOB >>>>>> data */ >>>>>> >>>>>> + char *buffer; /* just used when pagesize is greater > */ >>>>> Start sentence with capital letter >>>>> >>>>>> + /* than FCM RAM 2K limitation > */ >>>>>> }; >>>>>> >>>>>> /* These map to the positions used by the FCM hardware ECC >>>>>> generator */ >>>>>> >>>>>> @@ -159,6 +160,44 @@ static struct nand_bbt_descr bbt_mirror_descr = { >>>>>> >>>>>> .pattern = mirror_pattern, >>>>>> >>>>>> }; >>>>>> >>>>>> +static void io_to_buffer(struct mtd_info *mtd, int subpage, int oob) >>>>>> +{ >>>>>> + struct nand_chip *chip = mtd->priv; >>>>>> + struct fsl_elbc_mtd *priv = chip->priv; >>>>>> + struct fsl_elbc_ctrl *ctrl = priv->ctrl; >>>>>> + void *src, *dst; >>>>>> + int len = (oob ? 64 : 2048); >>>>> No parenthesis ... >>>>> >>>>>> + >>>>>> + /* for emulating 4096+ bytes NAND using 2048-byte FCM RAM */ >>>>>> + if (oob) >>>>>> + dst = ctrl->buffer + mtd->writesize + subpage * 64; >>>>>> + else >>>>>> + dst = ctrl->buffer + subpage * 2048; >>>>> subpage * len ? >>>> dst = ctrl->buffer + (oob ? mtd->writesize : 0) + subpage * len ? >>>> Is this important ? I think it is ok. >>> dst = ctrl->buffer + subpage * len; >>> >>> if (oob) >>> >>> dst += mtd->writesize; >>> >>> it's important, this code looks like mess. You introduce len and don't >>> use it anywhere then ? >> memcpy_fromio(dst, src, len); > Ok, why not use it consistently then. I think it is pellucid. I still don't think it is very important. - LiuShuo > M >