From: Naga Sureshkumar Relli <nagasure@xilinx.com>
To: Boris Brezillon <boris.brezillon@bootlin.com>
Cc: "miquel.raynal@bootlin.com" <miquel.raynal@bootlin.com>,
"richard@nod.at" <richard@nod.at>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
"computersforpeace@gmail.com" <computersforpeace@gmail.com>,
"marek.vasut@gmail.com" <marek.vasut@gmail.com>,
"kyungmin.park@samsung.com" <kyungmin.park@samsung.com>,
"absahu@codeaurora.org" <absahu@codeaurora.org>,
"peterpandong@micron.com" <peterpandong@micron.com>,
"frieder.schrempf@exceet.de" <frieder.schrempf@exceet.de>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Michal Simek <michals@xilinx.com>,
"nagasureshkumarrelli@gmail.com" <nagasureshkumarrelli@gmail.com>
Subject: RE: [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller
Date: Sat, 18 Aug 2018 05:49:32 +0000 [thread overview]
Message-ID: <MWHPR02MB2623D48B5DBAFCE2B5D03747AF3C0@MWHPR02MB2623.namprd02.prod.outlook.com> (raw)
In-Reply-To: <20180817195903.49963b25@bbrezillon>
Hi Boris,
Thanks for the review.
> -----Original Message-----
> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> Sent: Friday, August 17, 2018 11:29 PM
> To: Naga Sureshkumar Relli <nagasure@xilinx.com>
> Cc: miquel.raynal@bootlin.com; richard@nod.at; dwmw2@infradead.org;
> computersforpeace@gmail.com; marek.vasut@gmail.com; kyungmin.park@samsung.com;
> absahu@codeaurora.org; peterpandong@micron.com; frieder.schrempf@exceet.de; linux-
> mtd@lists.infradead.org; linux-kernel@vger.kernel.org; Michal Simek <michals@xilinx.com>;
> nagasureshkumarrelli@gmail.com
> Subject: Re: [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add support for Arasan
> NAND Flash Controller
>
> Hi Naga,
>
> On Fri, 17 Aug 2018 18:49:24 +0530
> Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> wrote:
>
> > +static int anfc_exec_op_cmd(struct nand_chip *chip,
> > + const struct nand_subop *subop) {
> > + const struct nand_op_instr *instr;
> > + struct anfc_op nfc_op = {};
> > + struct anfc_nand_chip *achip = to_anfc_nand(chip);
> > + struct anfc_nand_controller *nfc = to_anfc(chip->controller);
> > + struct mtd_info *mtd = nand_to_mtd(chip);
> > + u32 addrcycles;
> > + unsigned int op_id, len = 0;
> > + bool reading;
> > +
> > + anfc_parse_instructions(chip, subop, &nfc_op);
> > + instr = nfc_op.data_instr;
> > + op_id = nfc_op.data_instr_idx;
> > + if (nfc_op.data_instr)
> > + len = nand_subop_get_data_len(subop, op_id);
> > +
> > + /*
> > + * The switch case is to prepare a command and to set page/column
> > + * address. Arasan NAND controller has program register(Off: 0x10)),
> > + * which needs to be set for every command.
> > + * Ex: When NAND_CMD_RESET is issued, then we need to set reset bit
> > + * in program_register. etc..
> > + */
> > + switch (nfc_op.cmnds[0]) {
> > + case NAND_CMD_SEQIN:
> > + addrcycles = achip->raddr_cycles + achip->caddr_cycles;
> > +
> > + anfc_prepare_cmd(nfc, nfc_op.cmnds[0], NAND_CMD_PAGEPROG, 1,
> > + mtd->writesize, addrcycles);
> > + anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > + break;
> > + case NAND_CMD_READOOB:
> > + nfc_op.col += mtd->writesize;
> > + case NAND_CMD_READ0:
> > + case NAND_CMD_READ1:
> > + addrcycles = achip->raddr_cycles + achip->caddr_cycles;
> > + anfc_prepare_cmd(nfc, NAND_CMD_READ0, NAND_CMD_READSTART,
> 1,
> > + mtd->writesize, addrcycles);
> > + anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > + if (!nfc_op.data_instr)
> > + return 0;
> > +
> > + anfc_read_data_op(mtd, instr->ctx.data.buf.in, len);
> > + break;
> > + case NAND_CMD_RNDOUT:
> > + anfc_prepare_cmd(nfc, nfc_op.cmnds[0], NAND_CMD_RNDOUTSTART, 1,
> > + mtd->writesize, 2);
> > + anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > + nfc->prog = PROG_PGRD;
> > + break;
> > + case NAND_CMD_PARAM:
> > + anfc_prepare_cmd(nfc, nfc_op.cmnds[0], 0, 0, 0, 1);
> > + anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > + nfc->prog = PROG_RDPARAM;
> > + break;
> > + case NAND_CMD_READID:
> > + anfc_prepare_cmd(nfc, nfc_op.cmnds[0], 0, 0, 0, 1);
> > + anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > + nfc->prog = PROG_RDID;
> > + break;
> > + case NAND_CMD_GET_FEATURES:
> > + anfc_prepare_cmd(nfc, nfc_op.cmnds[0], 0, 0, 0, 1);
> > + anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > + nfc->prog = PROG_GET_FEATURE;
> > + break;
> > + case NAND_CMD_SET_FEATURES:
> > + anfc_prepare_cmd(nfc, nfc_op.cmnds[0], 0, 0, 0, 1);
> > + anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > + nfc->prog = PROG_SET_FEATURE;
> > + break;
> > + case NAND_CMD_ERASE1:
> > + anfc_erase_function(chip, nfc_op);
> > + break;
> > + default:
> > + break;
> > + }
>
> Looks like you have one of these smart controllers where everything is hardcoded and new
> commands (like vendor specific commands) can't be supported, and we're back to abusing -
> >exec_op(), just like ->cmdfunc() was abused.
Actually hardcoding commands with ->exec_op() interface in the driver is really looking weird.
I agree with that.
But as per the spec, for every command, we need to set respective bit in PROG_REG and because
Of this, we need to track the commands for each exec_op() call.
>
> Don't you have a way to send raw CMD/ADDR/DATA cycles? If not, then we'll have to
> consider other options, because I don't want to go back to the situation we are in with -
> >cmdfunc().
As I said above, for each command we need to set a bit in PROG_REG, to initiate the operation.
The only conflicting thing is that, setting a respective bit in PROG_REG based on the command
Needs command tracking.
>
> Maybe I already asked, but is there a public spec for this IP?
I didn't find any public spec for this IP, but you can find the register data base at below link
https://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html
and click on NAND.
There we have Command Reg(Off: 0x0C) and Program Reg(Off: 0x10), which describes the usage.
Also not in depth but at least something is documented in TRM
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
we can find the programming model in chapter 25.
Please let me know if I missed anything.
Thanks,
Naga Sureshkumar Relli.
>
> Thanks,
>
> Boris
next prev parent reply other threads:[~2018-08-18 5:50 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-17 13:19 [LINUX PATCH v10 0/2] Add support for Arasan NAND Flash controller Naga Sureshkumar Relli
2018-08-17 13:19 ` [LINUX PATCH v10 1/2] dt-bindings: mtd: arasan: Add device tree binding documentation Naga Sureshkumar Relli
2018-08-20 12:33 ` Boris Brezillon
2018-08-21 5:47 ` Naga Sureshkumar Relli
2018-08-21 5:59 ` Boris Brezillon
2018-08-21 9:22 ` Naga Sureshkumar Relli
2018-08-21 9:52 ` Miquel Raynal
2018-08-21 10:44 ` Naga Sureshkumar Relli
2018-08-21 10:52 ` Boris Brezillon
2018-08-21 11:10 ` Boris Brezillon
2018-08-17 13:19 ` [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller Naga Sureshkumar Relli
2018-08-17 14:37 ` Miquel Raynal
2018-08-18 4:48 ` Naga Sureshkumar Relli
2018-08-17 15:30 ` kbuild test robot
2018-08-17 17:59 ` Boris Brezillon
2018-08-18 5:49 ` Naga Sureshkumar Relli [this message]
2018-08-20 8:53 ` Boris Brezillon
2018-08-20 10:49 ` Naga Sureshkumar Relli
2018-08-20 12:10 ` Boris Brezillon
2018-08-20 12:21 ` Naga Sureshkumar Relli
2018-08-20 12:24 ` Boris Brezillon
2018-08-20 16:40 ` Boris Brezillon
2018-08-21 6:40 ` Naga Sureshkumar Relli
2018-08-21 7:31 ` Miquel Raynal
2018-09-11 5:23 ` Naga Sureshkumar Relli
2018-09-22 7:53 ` Miquel Raynal
2018-09-22 8:13 ` Boris Brezillon
2018-09-24 8:42 ` Naga Sureshkumar Relli
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=MWHPR02MB2623D48B5DBAFCE2B5D03747AF3C0@MWHPR02MB2623.namprd02.prod.outlook.com \
--to=nagasure@xilinx.com \
--cc=absahu@codeaurora.org \
--cc=boris.brezillon@bootlin.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=frieder.schrempf@exceet.de \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=michals@xilinx.com \
--cc=miquel.raynal@bootlin.com \
--cc=nagasureshkumarrelli@gmail.com \
--cc=peterpandong@micron.com \
--cc=richard@nod.at \
/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;
as well as URLs for NNTP newsgroup(s).