From: xiangsheng.hou <xiangsheng.hou@mediatek.com> To: Miquel Raynal <miquel.raynal@bootlin.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,v1 0/4] Add a driver for Mediatek SPI Nand controller Date: Mon, 11 Oct 2021 19:31:28 +0800 [thread overview] Message-ID: <cb200da61b942d93a272f3391f756c493cb5a342.camel@mediatek.com> (raw) In-Reply-To: <20211008112045.11e8d148@xps13> Hi Miquel, On Fri, 2021-10-08 at 11:20 +0200, Miquel Raynal wrote: > Hello, > > xiangsheng.hou@mediatek.com wrote on Mon, 27 Sep 2021 13:36:25 +0800: > > > Add a driver for Mediatek SPI Nand controller > > > > Mediatek SPI Nand controller cosists of two parts: on-host HW ECC > > and > > snfi(stand for spi nand flash interface). They can cowork with high > > performance which called ECC nfi mode. The nfi stand for nand flash > > interfacei(snfi a one part of nfi) which can support SPI Nand flash > > and raw nand flash. > > > > However, the snfi driver in spi subsytem need to be aware of nand > > parameter(page/spare size) and ecc status(enable/disable) when work > > at ECC nfi mode. The snfi driver in spi subsystem seems difficult > > to > > know these. > > > > Therefore, consider two ways to let snfi can get these information. > > The RFC patch send to review whether they are suitable and which > > solution maybe better. > > > > I've looked at both versions that you provided and I thought about a > number of things that cannot be done like this: > - I believe the snfi is a regular SPI controller. I will let Mark > confirm but I do not think we want to start writing SPI-NAND > controllers. Instead we write SPI controllers and we provide SPI- > mem > operations (we've explained this in a previous ELC, the video is > available on YouTube). The snfi controller can support multiple SPI protocols, which can support other SPI device in theory. However, the snfi need to know nand parameter and ecc status(enable/disable) when work with MTK on-host HW BCH ECC engine for nand flash. Therefore, the RFC patch v1/v2 is try the way to get these information. > - You cannot add an MTK ECC algorithm. This is dedicated for sofware > solutions only and as far as I understand your engine uses the BCH > algorithm. > - When the ECC engine is pipelined, there is an additional complexity > in interfacing it with a SPI controller (that's your case I > believe). > I have an example tintendhat is not yet upstream but I think worth > looking > at that I will send very soon (I will Cc: you on it). Thanks for your patch. MTK HW ECC(bch) algorithm can work in pipelined and external. However, the performance worse when work at ecternal which realize and verify in local. Therefore, try the pipelined in RFC patch v1/v2. And also realize the mtd/nand info can be get in spi driver which the spi-mxic driver in your patch. This may solve most of difficulty that encountered in the snfi driver that the RFC patch v1/v2 try to resolve. I will prepare the RFC patch v3 with correct pipelined ecc engine realization for your review. Thanks Xiangsheng Hou ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: xiangsheng.hou <xiangsheng.hou@mediatek.com> To: Miquel Raynal <miquel.raynal@bootlin.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,v1 0/4] Add a driver for Mediatek SPI Nand controller Date: Mon, 11 Oct 2021 19:31:28 +0800 [thread overview] Message-ID: <cb200da61b942d93a272f3391f756c493cb5a342.camel@mediatek.com> (raw) In-Reply-To: <20211008112045.11e8d148@xps13> Hi Miquel, On Fri, 2021-10-08 at 11:20 +0200, Miquel Raynal wrote: > Hello, > > xiangsheng.hou@mediatek.com wrote on Mon, 27 Sep 2021 13:36:25 +0800: > > > Add a driver for Mediatek SPI Nand controller > > > > Mediatek SPI Nand controller cosists of two parts: on-host HW ECC > > and > > snfi(stand for spi nand flash interface). They can cowork with high > > performance which called ECC nfi mode. The nfi stand for nand flash > > interfacei(snfi a one part of nfi) which can support SPI Nand flash > > and raw nand flash. > > > > However, the snfi driver in spi subsytem need to be aware of nand > > parameter(page/spare size) and ecc status(enable/disable) when work > > at ECC nfi mode. The snfi driver in spi subsystem seems difficult > > to > > know these. > > > > Therefore, consider two ways to let snfi can get these information. > > The RFC patch send to review whether they are suitable and which > > solution maybe better. > > > > I've looked at both versions that you provided and I thought about a > number of things that cannot be done like this: > - I believe the snfi is a regular SPI controller. I will let Mark > confirm but I do not think we want to start writing SPI-NAND > controllers. Instead we write SPI controllers and we provide SPI- > mem > operations (we've explained this in a previous ELC, the video is > available on YouTube). The snfi controller can support multiple SPI protocols, which can support other SPI device in theory. However, the snfi need to know nand parameter and ecc status(enable/disable) when work with MTK on-host HW BCH ECC engine for nand flash. Therefore, the RFC patch v1/v2 is try the way to get these information. > - You cannot add an MTK ECC algorithm. This is dedicated for sofware > solutions only and as far as I understand your engine uses the BCH > algorithm. > - When the ECC engine is pipelined, there is an additional complexity > in interfacing it with a SPI controller (that's your case I > believe). > I have an example tintendhat is not yet upstream but I think worth > looking > at that I will send very soon (I will Cc: you on it). Thanks for your patch. MTK HW ECC(bch) algorithm can work in pipelined and external. However, the performance worse when work at ecternal which realize and verify in local. Therefore, try the pipelined in RFC patch v1/v2. And also realize the mtd/nand info can be get in spi driver which the spi-mxic driver in your patch. This may solve most of difficulty that encountered in the snfi driver that the RFC patch v1/v2 try to resolve. I will prepare the RFC patch v3 with correct pipelined ecc engine realization for your review. Thanks Xiangsheng Hou _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek
next prev parent reply other threads:[~2021-10-11 11:43 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-27 5:36 [RFC,v1 0/4] Add a driver for Mediatek SPI Nand controller Xiangsheng Hou 2021-09-27 5:36 ` Xiangsheng Hou 2021-09-27 5:36 ` [RFC,v1 1/4] mtd: ecc: move mediatek HW ECC driver Xiangsheng Hou 2021-09-27 5:36 ` Xiangsheng Hou 2021-09-27 5:36 ` [RFC,v1 2/4] mtd: ecc: realize Mediatek " Xiangsheng Hou 2021-09-27 5:36 ` Xiangsheng Hou 2021-09-27 5:36 ` [RFC,v1 3/4] spi: add Mediatek SPI Nand controller driver Xiangsheng Hou 2021-09-27 5:36 ` Xiangsheng Hou 2021-09-27 5:36 ` [RFC,v1 4/4] arm64: dts: add snfi node for spi nand Xiangsheng Hou 2021-09-27 5:36 ` Xiangsheng Hou 2021-10-08 9:20 ` [RFC,v1 0/4] Add a driver for Mediatek SPI Nand controller Miquel Raynal 2021-10-08 9:20 ` Miquel Raynal 2021-10-11 11:31 ` xiangsheng.hou [this message] 2021-10-11 11:31 ` xiangsheng.hou 2021-10-11 14:31 ` Miquel Raynal 2021-10-11 14:31 ` Miquel Raynal
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=cb200da61b942d93a272f3391f756c493cb5a342.camel@mediatek.com \ --to=xiangsheng.hou@mediatek.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=miquel.raynal@bootlin.com \ --cc=rdlee@amazon.com \ --cc=sanny.chen@mediatek.com \ --cc=srv_heupstream@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: linkBe 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.