From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "xiangsheng.hou" <xiangsheng.hou@mediatek.com>
Cc: <broonie@kernel.org>, <benliang.zhao@mediatek.com>,
<dandan.he@mediatek.com>, <guochun.mao@mediatek.com>,
<bin.zhang@mediatek.com>, <sanny.chen@mediatek.com>,
<mao.zhong@mediatek.com>, <yingjoe.chen@mediatek.com>,
<donghunt@amazon.com>, <rdlee@amazon.com>,
<linux-mtd@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>,
<srv_heupstream@mediatek.com>
Subject: Re: [RFC,v4,2/5] mtd: nand: ecc: mtk: Convert to the ECC infrastructure
Date: Fri, 10 Dec 2021 10:34:26 +0100 [thread overview]
Message-ID: <20211210103426.0850d8d5@xps13> (raw)
In-Reply-To: <c7367dccd7b159ed36fd7d19fef25b0df8c5782d.camel@mediatek.com>
Hello,
xiangsheng.hou@mediatek.com wrote on Fri, 10 Dec 2021 17:09:14 +0800:
> Hi Miquel,
>
> On Thu, 2021-12-09 at 11:32 +0100, Miquel Raynal wrote:
> > Hi Xiangsheng,
> >
> > xiangsheng.hou@mediatek.com wrote on Tue, 30 Nov 2021 16:31:59 +0800:
> >
> > >
> > > +static void mtk_ecc_no_bbm_swap(struct nand_device *a, u8 *b, u8
> > > *c)
> > > +{
> > > + /* nop */
> >
> > Is this really useful?
>
> For 512 bytes page size, it is no need to do BBM swap due to the ECC
> engine step size will be 512 bytes.
>
> However, there have 512 bytes SLC NAND page size in history, although
> have not seen such SPI/Parallel NAND device for now.
>
> Do you think there no need to consider this small page device?
Actually I was talking about the empty helper itself. But let's keep
that aside for now, it's fine.
>
> >
> > > +}
> > > +
> > > +static void mtk_ecc_bbm_swap(struct nand_device *nand, u8
> > > *databuf, u8 *oobbuf)
> > > +{
> > > + struct mtk_ecc_engine *eng = nand_to_ecc_ctx(nand);
> > > + int step_size = nand->ecc.ctx.conf.step_size;
> > > + u32 bbm_pos = eng->bbm_ctl.position;
> > > +
> > > + bbm_pos += eng->bbm_ctl.section * step_size;
> > > +
> > > + swap(oobbuf[0], databuf[bbm_pos]);
> > > +}
> > > +
> > > +static void mtk_ecc_set_bbm_ctl(struct mtk_ecc_bbm_ctl *bbm_ctl,
> > > + struct nand_device *nand)
> > > +{
> > > + if (nanddev_page_size(nand) == 512) {
> > > + bbm_ctl->bbm_swap = mtk_ecc_no_bbm_swap;
> > > + } else {
> > > + bbm_ctl->bbm_swap = mtk_ecc_bbm_swap;
> > > + bbm_ctl->section = nanddev_page_size(nand) /
> > > + mtk_ecc_data_len(nand);
> > > + bbm_ctl->position = nanddev_page_size(nand) %
> > > + mtk_ecc_data_len(nand);
> > > + }
> > > +}
> > >
> > > +
> > > +static struct device *mtk_ecc_get_engine_dev(struct device *dev)
> > > +{
> > > + struct platform_device *eccpdev;
> > > + struct device_node *np;
> > > +
> > > + /*
> > > + * The device node is only the host controller,
> > > + * not the actual ECC engine when pipelined case.
> > > + */
> > > + np = of_parse_phandle(dev->of_node, "nand-ecc-engine", 0);
> > > + if (!np)
> > > + return NULL;
> > > +
> > > + eccpdev = of_find_device_by_node(np);
> > > + if (!eccpdev) {
> > > + of_node_put(np);
> > > + return NULL;
> > > + }
> > > +
> > > + platform_device_put(eccpdev);
> > > + of_node_put(np);
> > > +
> > > + return &eccpdev->dev;
> > > +}
> >
> > As this will be the exact same function for all the pipelined
> > engines,
> > I am tempted to put this in the core. I'll soon send a iteration,
> > stay
> > tuned.
> >
>
> Look forward to the function.
I sent the new version yesterday but I
* forgot to CC: you
* forgot about that function as well
Let's ignore this comment for now, send your driver with the same
function in it and I'll clean that up later.
Here is the new iteration, sorry for forgetting to send it to you as
well:
https://lore.kernel.org/linux-mtd/20211209174046.535229-1-miquel.raynal@bootlin.com/T/
And here is a Github branch as well:
https://github.com/miquelraynal/linux/tree/ecc-engine
> > > + struct nand_page_io_req *req)
> > > +{
> > > + struct mtk_ecc_engine *eng = nand_to_ecc_ctx(nand);
> > > + int step_size = nand->ecc.ctx.conf.step_size;
> > > + void *databuf, *oobbuf;
> > > + int i;
> > > +
> > > + if (req->type == NAND_PAGE_WRITE) {
> > > + databuf = (void *)req->databuf.out;
> > > + oobbuf = (void *)req->oobbuf.out;
> > > +
> > > + /*
> > > + * Convert the source databuf and oobbuf to MTK ECC
> > > + * on-flash data format.
> > > + */
> > > + for (i = 0; i < eng->nsteps; i++) {
> > > + if (i == eng->bbm_ctl.section)
> > > + eng->bbm_ctl.bbm_swap(nand,
> > > + databuf, oobbuf);
> >
> > Do you really need this swap? Isn't the overall move enough to put
> > the
> > BBM at the right place?
> >
>
> For OPS_RAW mode, need organize flash data in the MTK ECC engine data
> format. Other operation in this function only organize data by section
> and not include BBM swap.
>
> For other mode, this function will not be called.
Can you try to explain this with an ascii schema again? I'm sorry but I
don't follow it. Is the BBM placed in the first bytes of the first oob
area by the engine? Or is it place somewhere else?
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2021-12-10 9:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-30 8:31 [RFC,v4,0/5] Add Mediatek SPI Nand controller and convert ECC driver Xiangsheng Hou
2021-11-30 8:31 ` [RFC,v4,1/5] mtd: nand: ecc: Move mediatek " Xiangsheng Hou
2021-11-30 8:31 ` [RFC,v4,2/5] mtd: nand: ecc: mtk: Convert to the ECC infrastructure Xiangsheng Hou
2021-12-09 10:32 ` Miquel Raynal
2021-12-10 9:09 ` xiangsheng.hou
2021-12-10 9:34 ` Miquel Raynal [this message]
2021-12-11 3:25 ` xiangsheng.hou
2021-12-13 9:29 ` Miquel Raynal
2021-12-14 3:32 ` xiangsheng.hou
2021-12-14 9:47 ` Miquel Raynal
2021-11-30 8:32 ` [RFC,v4,3/5] spi: mtk: Add mediatek SPI Nand Flash interface driver Xiangsheng Hou
2021-12-09 10:20 ` Miquel Raynal
2021-12-10 9:09 ` xiangsheng.hou
2021-12-10 9:40 ` Miquel Raynal
2021-11-30 8:32 ` [RFC, v4, 4/5] mtd: spinand: Move set/get OOB databytes to each ECC engines Xiangsheng Hou
2021-12-14 11:41 ` [RFC,v4,4/5] " Miquel Raynal
2021-12-20 7:37 ` xiangsheng.hou
2021-11-30 8:32 ` [RFC,v4,5/5] arm64: dts: mtk: Add snfi node Xiangsheng Hou
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=20211210103426.0850d8d5@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=benliang.zhao@mediatek.com \
--cc=bin.zhang@mediatek.com \
--cc=broonie@kernel.org \
--cc=dandan.he@mediatek.com \
--cc=donghunt@amazon.com \
--cc=guochun.mao@mediatek.com \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mao.zhong@mediatek.com \
--cc=rdlee@amazon.com \
--cc=sanny.chen@mediatek.com \
--cc=srv_heupstream@mediatek.com \
--cc=xiangsheng.hou@mediatek.com \
--cc=yingjoe.chen@mediatek.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;
as well as URLs for NNTP newsgroup(s).