From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: linux-mtd@lists.infradead.org, Dipen.Dudhat@freescale.com,
Ronak Desai <ronak.desai@rockwellcollins.com>
Subject: Re: [PATCH] fsl_ifc_nand: Added random output enable cmd
Date: Tue, 6 Sep 2016 21:50:03 +0200 [thread overview]
Message-ID: <20160906215003.1b6eb095@bbrezillon> (raw)
In-Reply-To: <1473189197-45191-1-git-send-email-matthew.weber@rockwellcollins.com>
On Tue, 6 Sep 2016 14:13:17 -0500
Matt Weber <matthew.weber@rockwellcollins.com> wrote:
> This patch adds random output enable command support in IFC nand
> controller driver. This command implements change read
> column (05h-E0h).
>
> Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
> Signed-off-by: Ronak Desai <ronak.desai@rockwellcollins.com>
> ---
> drivers/mtd/nand/fsl_ifc_nand.c | 30 +++++++++++++++++++++++++++---
> 1 file changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
> index 4e9e5fd..230919f 100644
> --- a/drivers/mtd/nand/fsl_ifc_nand.c
> +++ b/drivers/mtd/nand/fsl_ifc_nand.c
> @@ -387,10 +387,11 @@ static void fsl_ifc_cmdfunc(struct mtd_info *mtd, unsigned int command,
>
> /*
> * although currently it's 8 bytes for READID, we always read
> - * the maximum 256 bytes(for PARAM)
> + * the maximum 8192 bytes(for PARAM) supported by IFC controller
> + * as extended page may be available for some NAND devices.
> */
> - ifc_out32(256, &ifc->ifc_nand.nand_fbcr);
> - ifc_nand_ctrl->read_bytes = 256;
> + ifc_out32(0, &ifc->ifc_nand.nand_fbcr); /* Read whole page */
> + ifc_nand_ctrl->read_bytes = 8192; /* Maximum supported page by IFC */
And this exactly why letting drivers implement their own ->cmdfunc()
method is a bad idea.
->cmdfunc() does not provide enough information to guess how much data
should be read or written. Actually it's not supposed to be used this
way, but drivers usually abuse it.
I know you're just adding support for a new feature here, and I don't
blame you, but this kind of things make the whole NAND framework
impossible to maintain.
>
> set_addr(mtd, 0, 0, 0);
> fsl_ifc_run_command(mtd);
> @@ -530,6 +531,29 @@ static void fsl_ifc_cmdfunc(struct mtd_info *mtd, unsigned int command,
> fsl_ifc_run_command(mtd);
> return;
>
> + case NAND_CMD_RNDOUT: {
> + __le16 Tccs = 0;
> + chip->onfi_version ? (Tccs = chip->onfi_params.t_ccs)
> + : (Tccs = chip->jedec_params.t_ccs);
> + ifc_out32((IFC_FIR_OP_CW0 << IFC_NAND_FIR0_OP0_SHIFT) |
> + (IFC_FIR_OP_CA0 << IFC_NAND_FIR0_OP1_SHIFT) |
> + (IFC_FIR_OP_CMD1 << IFC_NAND_FIR0_OP2_SHIFT) |
> + (IFC_FIR_OP_NWAIT << IFC_NAND_FIR0_OP3_SHIFT),
> + &ifc->ifc_nand.nand_fir0);
> +
> + ifc_out32((NAND_CMD_RNDOUT << IFC_NAND_FCR0_CMD0_SHIFT) |
> + (NAND_CMD_RNDOUTSTART << IFC_NAND_FCR0_CMD1_SHIFT),
> + &ifc->ifc_nand.nand_fcr0);
> +
> + /* Wait for minimum change column set-up time. But it does not harm
> + * to wait more time, so calculated based on 333.3 MHz input IFC clock
> + */
Can't you know the clk rate at runtime instead of basing your
calculation on the hypothetic clk rate?
> + ifc_out32((0xFF & (le16_to_cpu(Tccs)/3)), &ifc->ifc_nand.ncfgr);
Why is it done in ->cmdfunc()? I mean, this timing parameter should be
set for all operations, and applied as soon as ->select_chip() is
called.
> + set_addr(mtd, column, 0, 0);
> + fsl_ifc_run_command(mtd);
> + return;
> + }
> +
> default:
> dev_err(priv->dev, "%s: error, unsupported command 0x%x.\n",
> __func__, command);
next prev parent reply other threads:[~2016-09-06 19:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-06 19:13 [PATCH] fsl_ifc_nand: Added random output enable cmd Matt Weber
2016-09-06 19:50 ` Boris Brezillon [this message]
2016-09-06 20:37 ` Ronak Desai
2016-09-07 5:05 ` Matthew Weber
2016-09-07 6:03 ` Scott Wood
2016-09-07 7:22 ` Boris Brezillon
2016-09-07 14:50 ` Ronak Desai
2016-09-07 16:15 ` Boris Brezillon
2016-09-07 23:31 ` Scott Wood
2016-09-23 5:57 ` Prabhakar Kushwaha
2016-09-07 23:18 ` Scott Wood
2016-09-08 5:57 ` Boris Brezillon
2016-09-09 3:00 ` Scott Wood
2016-09-09 7:40 ` Boris Brezillon
2016-09-09 18:30 ` Scott Wood
2016-09-12 19:01 ` Boris Brezillon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160906215003.1b6eb095@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=Dipen.Dudhat@freescale.com \
--cc=linux-mtd@lists.infradead.org \
--cc=matthew.weber@rockwellcollins.com \
--cc=ronak.desai@rockwellcollins.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.