All of lore.kernel.org
 help / color / mirror / Atom feed
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-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
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/

  reply	other threads:[~2021-12-13  9:32 UTC|newest]

Thread overview: 36+ 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 ` Xiangsheng Hou
2021-11-30  8:31 ` [RFC,v4,1/5] mtd: nand: ecc: Move mediatek " Xiangsheng Hou
2021-11-30  8:31   ` Xiangsheng Hou
2021-11-30  8:31 ` [RFC,v4,2/5] mtd: nand: ecc: mtk: Convert to the ECC infrastructure Xiangsheng Hou
2021-11-30  8:31   ` Xiangsheng Hou
2021-12-09 10:32   ` Miquel Raynal
2021-12-09 10:32     ` Miquel Raynal
2021-12-10  9:09     ` xiangsheng.hou
2021-12-10  9:09       ` xiangsheng.hou
2021-12-10  9:34       ` Miquel Raynal
2021-12-10  9:34         ` Miquel Raynal
2021-12-11  3:25         ` xiangsheng.hou
2021-12-11  3:25           ` xiangsheng.hou
2021-12-13  9:29           ` Miquel Raynal [this message]
2021-12-13  9:29             ` Miquel Raynal
2021-12-14  3:32             ` xiangsheng.hou
2021-12-14  3:32               ` xiangsheng.hou
2021-12-14  9:47               ` Miquel Raynal
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-11-30  8:32   ` Xiangsheng Hou
2021-12-09 10:20   ` Miquel Raynal
2021-12-09 10:20     ` Miquel Raynal
2021-12-10  9:09     ` xiangsheng.hou
2021-12-10  9:09       ` xiangsheng.hou
2021-12-10  9:40       ` Miquel Raynal
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-11-30  8:32   ` Xiangsheng Hou
2021-12-14 11:41   ` [RFC,v4,4/5] " Miquel Raynal
2021-12-14 11:41     ` Miquel Raynal
2021-12-20  7:37     ` xiangsheng.hou
2021-12-20  7:37       ` xiangsheng.hou
2021-11-30  8:32 ` [RFC,v4,5/5] arm64: dts: mtk: Add snfi node Xiangsheng Hou
2021-11-30  8:32   ` 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 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.