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>, <info@bootlin.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: Fri, 8 Oct 2021 11:20:45 +0200	[thread overview]
Message-ID: <20211008112045.11e8d148@xps13> (raw)
In-Reply-To: <20210927053629.17847-1-xiangsheng.hou@mediatek.com>

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.
> 
> RFC patch v1:
> Add nfi register base at bch(ecc) dts node and config nand parameter
> and ecc status into nfi registers in ecc driver, then parse these
> information at snfi driver to use.
> 
> RFC patch v2:
> Export some function in HW ECC driver and snfi driver.
> In HW ECC driver, export function include get nand page/spare size, HW
> ECC status(enable/disable) and fdm(oob free per sector in ooblayout) size.
> In snfi driver need export empty page status which the nfi can be aware
> when in ECC nfi mode(the spim framework can not return this information).
> 

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).
- 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 that is not yet upstream but I think worth looking
  at that I will send very soon (I will Cc: you on it).
- The DT description for those engines that has been described on the
  mailing list and will be enforced is:

// External engine

	&spi-controller {
                flash@0 {
                        compatible = "spi-nand";
                        reg = <0>;
                        nand-ecc-engine = <&ecc_engine>;
                        spi-max-frequency = <50000000>;
                        spi-tx-bus-width = <4>;
                        spi-rx-bus-width = <4>;
                };
        };

        ecc_engine: ecc@43c40000 {
                compatible = "mxic,nand-ecc-engine-rev3";
                reg = <0x43c40000 0x10000>;
        };
 

// Pipelined engine

	&spi-controller {
               nand-ecc-engine = <&ecc_engine>;
 
                flash@0 {
                        compatible = "spi-nand";
                        reg = <0>;
                        nand-ecc-engine = <&spi_controller>;
                        spi-max-frequency = <50000000>;
                        spi-tx-bus-width = <4>;
                        spi-rx-bus-width = <4>;
 		};
	};

        ecc_engine: ecc@43c40000 {
                compatible = "mxic,nand-ecc-engine-rev3";
                reg = <0x43c40000 0x10000>;
        };

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>, <info@bootlin.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: Fri, 8 Oct 2021 11:20:45 +0200	[thread overview]
Message-ID: <20211008112045.11e8d148@xps13> (raw)
In-Reply-To: <20210927053629.17847-1-xiangsheng.hou@mediatek.com>

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.
> 
> RFC patch v1:
> Add nfi register base at bch(ecc) dts node and config nand parameter
> and ecc status into nfi registers in ecc driver, then parse these
> information at snfi driver to use.
> 
> RFC patch v2:
> Export some function in HW ECC driver and snfi driver.
> In HW ECC driver, export function include get nand page/spare size, HW
> ECC status(enable/disable) and fdm(oob free per sector in ooblayout) size.
> In snfi driver need export empty page status which the nfi can be aware
> when in ECC nfi mode(the spim framework can not return this information).
> 

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).
- 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 that is not yet upstream but I think worth looking
  at that I will send very soon (I will Cc: you on it).
- The DT description for those engines that has been described on the
  mailing list and will be enforced is:

// External engine

	&spi-controller {
                flash@0 {
                        compatible = "spi-nand";
                        reg = <0>;
                        nand-ecc-engine = <&ecc_engine>;
                        spi-max-frequency = <50000000>;
                        spi-tx-bus-width = <4>;
                        spi-rx-bus-width = <4>;
                };
        };

        ecc_engine: ecc@43c40000 {
                compatible = "mxic,nand-ecc-engine-rev3";
                reg = <0x43c40000 0x10000>;
        };
 

// Pipelined engine

	&spi-controller {
               nand-ecc-engine = <&ecc_engine>;
 
                flash@0 {
                        compatible = "spi-nand";
                        reg = <0>;
                        nand-ecc-engine = <&spi_controller>;
                        spi-max-frequency = <50000000>;
                        spi-tx-bus-width = <4>;
                        spi-rx-bus-width = <4>;
 		};
	};

        ecc_engine: ecc@43c40000 {
                compatible = "mxic,nand-ecc-engine-rev3";
                reg = <0x43c40000 0x10000>;
        };

Thanks,
Miquèl

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

  parent reply	other threads:[~2021-10-08  9:21 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 ` Miquel Raynal [this message]
2021-10-08  9:20   ` [RFC,v1 0/4] Add a driver for Mediatek SPI Nand controller Miquel Raynal
2021-10-11 11:31   ` xiangsheng.hou
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=20211008112045.11e8d148@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=info@bootlin.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.