Re: Mediatek SPI Nand controller driver design for upstream

Re: Mediatek SPI Nand controller driver design for upstream

[xiangsheng.hou]

Retitle

Hi Miquel,

As talked before, I developed the 1st driver for Mediatek SPI Nand
controller. However, there have performance issue in 1st version(read
speed reduce 42% and write speed reduce 15%).

The controller consists of two parts snfi(stand for serial nand flash
interface) for spim and hw ecc for generic ecc engine. They can cowrok
or work independent.

The 1st driver realized in the way of working independently, due to the
cowork need get nand parameter(page size and spare size) for snfi and
hw ecc. However, the snfi in spi subsystem seems difficult to get nand
parameter.

Therefore, I thought of two ways let snfi in spi subsystem get nand
parameter to improve performance.

1) Export some function in mediatek hw ecc driver. And called by snfi
driver in spi subsystem to let snfi get nand parameter and ecc disable
or not.

2) Add snfi reg in ecc dts node, config snfi regs(get by of_iomap) with
nand parameter in hw ecc driver. And snfi driver parse nand parameter
in snfi regs to use.

May I have your opinion about whether they are suitable and which maybe
better.

Thanks

On Wed, 2021-09-01 at 18:20 +0800, Xiangsheng Hou (侯祥胜) wrote:
> Hi Miquel,
> 
> > Actually I don't have the time to dig into this problem, would you
> > mind proposing a patch on the mailing list? Or maybe if you don't
> > have the resources internally we could open a contracting
> > discussion?
> 
> I`m coding and testing based on Mediatek SPI Nand controller by some
> workaround with the auto oob issue for now.  
> I will check the issue thoroughly, but use HW ECC on my board.
> 
> In addition,  I found performance issue when force Mediatek SPI Nand
> controller fit to current ECC & SPI Nand  & SPI Mem framework.
> 
> 1. Introduction about Mediatek SPI Nand controller
> The Mediatek SPI Nand controller consists of two parts HW ECC and nfi
> (stand for nand flash interface)
> The HW ECC have 3 source data mode:
> 1) pio mode: means source data is written by MCU
> 2) dma mode: means source data from AHB Bus
> 3) nfi mode: means source data from NFI module, can automatically
> generate ECC syndrome bits when programming or reading the device.
> 
> 2. ECC nfi mode & dma mode data flow
> 1) dma mode (read flow for example)
> 
> The HW ECC engine get source data after the nfi engine get data from
> nand device. And, the HW ECC engine decode/encode data by sector for
> each.
> 
> 2)nfi mode(read flow for example)
>                              
> The nfi and HW ECC can cooperation with HW share buf in nfi mode
> without another dma transfer. 
> HW ECC can get source data and decode/encode during nfi data
> transmission from nand device.
> And, the HW ECC engine decode/encode by sector in pipeline.
> 
> 3. Current driver implementation
> Mode 1) & 2) means the HW ECC engine can work independent to nfi
> engine. HW ECC responsible for data encode/decode. nfi responsible
> for data transfer.
> These look like can fit to current SPI Nand framework. The HW ECC
> driver realize the ecc engine at mtd layer, the nfi realize spi
> driver at spi layer.
> Of course, the ecc driver choose the mode 2) dma mode for high
> performance.
> 
> 4.Performance comparison
> However, the ecc and nfi driver which fit to upstream framework have
> poor performance compare with the driver(private driver direct
> realize mtd function ) use ECC nfi mode which not fit framework.
> Take some performance information tested by mtd_speedtest, read speed
> reduce 42% and write speed reduce 15%.
> 
> May I have your some suggestion for the performance issue with the
> realization of Mediatek SPI Nand controller driver.
> 
> Thanks
> Xiangsheng Hou
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek