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: Mon, 13 Dec 2021 10:29:56 +0100 [thread overview]
Message-ID: <20211213102956.559e98a1@xps13> (raw)
In-Reply-To: <4debdf60521d13a2ee54e65fa2f545040e74fed7.camel@mediatek.com>
Hi Xiangsheng,
xiangsheng.hou@mediatek.com wrote on Sat, 11 Dec 2021 11:25:46 +0800:
> Hi Miquel,
>
> On Fri, 2021-12-10 at 10:34 +0100, Miquel Raynal wrote:
> > Hello,
> >
> > xiangsheng.hou@mediatek.com wrote on Fri, 10 Dec 2021 17:09:14 +0800:
> > >
> > > > 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
>
> Got it, Thanks.
>
> >
> > > > > + 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?
> >
>
> Yes, the BBM will at the first OOB area in NAND standard layout after
> BBM swap.
>
> 0. Differential on-flash data layout
>
> NAND standard page layout
> +------------------------------+------------+
> | | |
> | main area | OOB area |
> | | |
> +------------------------------+------------+
>
> MTK ECC on-flash page layout (2 section for example)
> +------------+--------+------------+--------+
> | | | | |
> | section(0) | OOB(0) | section(1) | OOB(1) |
> | | | | |
> +------------+--------+------------+--------+
I think we are aligned on that part.
The BBM is purely a user conception, it is not something wired in the
hardware. What I mean is: why do *you* think the BBM should be located
in the middle of section #1 ?
There is one layout: the layout from the NAND/MTD perspective.
There is another layout: the layout of your ECC engine.
Just consider that the BBM should be at byte 0 of OOB #0 and you will
not need any BBM swap operation anymore. I don't understand why you
absolutely want to put it in section #1.
> The standard BBM position will be section(1) main data,
> need do the BBM swap operation.
>
> request buffer include req->databuf and req->oobbuf.
> +----------------------------+
> | |
> | req->databuf |
> | |
> +----------------------------+
>
> +-------------+
> | |
> | req->oobbuf |
> | |
> +-------------+
>
> 1. For the OPS_RAW mode
>
> Expect the on-flash data format is like MTK ECC layout.
> The snfi controller will put the on-flash data as is
> spi_mem_op->data.buf.out.
>
> Therefore, the ECC engine have to reorganize the request
> data and OOB buffer in 4 part for each section in
> OPS_RAW mode.
>
> 1) BBM swap, only for the section need do the swap
> 2) section main data
> 3) OOB free data
> 4) OOB ECC data
>
> The BBM swap will ensure the BBM position in MTK ECC
> on-flash layout is same as NAND standard layout in
> OPS_RAW mode.
>
> for (i = 0; i < eng->nsteps; i++) {
>
> /* part 1: BBM swap */
> if (i == eng->bbm_ctl.section)
> eng->bbm_ctl.bbm_swap(nand,
> databuf, oobbuf);
>
> /* part 2: main data in this section */
> memcpy(mtk_ecc_section_ptr(nand, i),
> databuf + mtk_ecc_data_off(nand, i),
> step_size);
>
> /* part 3: OOB free data */
> memcpy(mtk_ecc_oob_free_ptr(nand, i),
> oobbuf + mtk_ecc_oob_free_position(nand, i),
> eng->oob_free);
>
> /* part 4: OOB ECC data */
> memcpy(mtk_ecc_oob_free_ptr(nand, i) + eng->oob_free,
> oobbuf + eng->oob_free * eng->nsteps +
> i * eng->oob_ecc,
> eng->oob_ecc);
> }
>
> 2. For non OPS_RAW mode
>
> The snfi have a function called auto format with ECC enable.
> This will auto reorganize the request data and oob data in
> MTK ECC page layout by the snfi controller except the BBM position.
>
> Therefore, the ECC engine only need do the BBM swap after set OOB data
> bytes in OPS_AUTO or after memcpy oob data in OPS_PLACE_OOB for write
> operation.
>
> The BBM swap also ensure the BBM position in MTK ECC on-flash
> layout is
> same as NAND standard layout in non OPS_RAW mode.
>
> if (req->ooblen) {
> if (req->mode == MTD_OPS_AUTO_OOB) {
> ret = mtd_ooblayout_set_databytes(mtd,
> req->oobbuf.out,
> eng->bounce_oob_buf,
> req->ooboffs,
> mtd->oobavail);
> if (ret)
> return ret;
> } else {
> memcpy(eng->bounce_oob_buf + req->ooboffs,
> req->oobbuf.out,
> req->ooblen);
> }
> }
>
> eng->bbm_ctl.bbm_swap(nand, (void *)req->databuf.out,
> eng->bounce_oob_buf);
>
> Thanks
> Xiangsheng Hou
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2021-12-13 9:32 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
2021-12-11 3:25 ` xiangsheng.hou
2021-12-13 9:29 ` Miquel Raynal [this message]
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=20211213102956.559e98a1@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