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,v1 0/4] Add a driver for Mediatek SPI Nand controller
Date: Mon, 11 Oct 2021 16:31:08 +0200	[thread overview]
Message-ID: <20211011163108.256752eb@xps13> (raw)
In-Reply-To: <cb200da61b942d93a272f3391f756c493cb5a342.camel@mediatek.com>

Hello,

xiangsheng.hou@mediatek.com wrote on Mon, 11 Oct 2021 19:31:28 +0800:

> 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.

Yes this is completely expected as the data must be moved twice instead
of once. I believe pipelined mode is harder to implement in software but
brings better performances.

> 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.

Great, that was indeed the goal.

> I will prepare the RFC patch v3 with correct pipelined ecc engine
> realization for your review.

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,v1 0/4] Add a driver for Mediatek SPI Nand controller
Date: Mon, 11 Oct 2021 16:31:08 +0200	[thread overview]
Message-ID: <20211011163108.256752eb@xps13> (raw)
In-Reply-To: <cb200da61b942d93a272f3391f756c493cb5a342.camel@mediatek.com>

Hello,

xiangsheng.hou@mediatek.com wrote on Mon, 11 Oct 2021 19:31:28 +0800:

> 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.

Yes this is completely expected as the data must be moved twice instead
of once. I believe pipelined mode is harder to implement in software but
brings better performances.

> 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.

Great, that was indeed the goal.

> I will prepare the RFC patch v3 with correct pipelined ecc engine
> realization for your review.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2021-10-11 14:31 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
2021-10-11 11:31     ` xiangsheng.hou
2021-10-11 14:31     ` Miquel Raynal [this message]
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=20211011163108.256752eb@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.