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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox