archive mirror
 help / color / mirror / Atom feed
From: Chuanhong Guo <>
To: Boris Brezillon
Cc: "Xiangsheng Hou"
	"Benliang Zhao (赵本亮)"
	"Bayi Cheng (程八意)"
	"Mark Brown" <>
Subject: Re: [PATCH 3/3] spi: spi-mem: MediaTek: Add SPI NAND Flash interface driver for MediaTek MT7622
Date: Wed, 11 Mar 2020 15:31:29 +0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20181026080833.2fedbd94@bbrezillon>

Hi Boris!

I'm about to pick this driver up and start upstream it in the future.
So I'm answering
your questions below and would like to get your further suggestions.

On Fri, Oct 26, 2018 at 2:09 PM Boris Brezillon
<> wrote:
> > > There's a fundamental issue with this driver: spi-mem was designed to be
> > > memory agnostic, and you seem to have a SPI controller that supports
> > > only SPI NANDs. Is that correct, or is it just that you developed the
> > > driver with SPI NANDs in  mind?
> > >
> > Yes, this driver supports only SPI NANDs.
> > Actually, Mediatek's controller is designed for NAND specifically, which
> > can support SPI NANDs and PARALLEL NANDs,and this driver is just for SPI
> > NANDs.
> Hm, I'm not so sure about that (I might be wrong though), it seems you
> can send any command you want, not only SPI NAND related ones. Maybe the
> controller is optimized for SPI NANDs but can do all kind of SPI
> transfers.

You are correct here. This controller can perform generic spi-mem operations,
and it has special routines for page cache R/W that utilize controller's ECC
functionality. I think the purpose of this is to provide better ECC capability
for some SPI NANDs with worse ECC algorithm on chip.

> > > Don't know what's possible to do with your controller, and maybe it's
> > > not able to execute random SPI memory operations, but in this case we
> > > should consider a different solution to support this driver.
> > >
> > > Do you have a public datasheet I can look at?
> > >
> > We do not have a public datasheet for Mediatek controller currently.
> Unfortunately, there's not much I can do without a clear understanding
> of how the controller works.

I found a public datasheet [0] on wiki page for Banana Pi R64 [1].
Register description is available under "NAND flash interface" section
starting at page 592.
There's a hackier version of this driver in OpenWrt [2] which checks
opcode and use controller routine for page cache R/W.

ECC part of this controller can also be used as a standalone ECC
algorithm and perform ECC operations on data provided by CPU.
But I think if it's implement this way, we wasted the page cache
R/W routines in this controller.

I have two other initial thoughts:
1. abstract some kind of ECC functionality in spi-mem interface
    I haven't really learned ECC stuff so I don't know whether this is
    possible and what kind of argument we needs for it.
2. modify SPI-NAND core to add support for special SPI-NAND controller.
    This limits controller's ability and adds extra burden for future extention
    of SPI-NAND framework.

Which way would you prefer and do you have other suggestions?

Chuanhong Guo

  reply	other threads:[~2020-03-11  7:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
     [not found]   ` <1536716612-24610-4-git-send-email-xiangsheng.hou-NuS5LvNUpcJWk0Htik3J/>
2018-10-23  5:52     ` Boris Brezillon
     [not found]       ` <1540532796.24602.11.camel@mhfsdcap03>
2018-10-26  6:08         ` Boris Brezillon
2020-03-11  7:31           ` Chuanhong Guo [this message]
     [not found]             ` <>
     [not found]               ` <>
     [not found]                 ` <20200311091813.41b55a97-ZGY8ohtN/>
2020-03-11  9:15                   ` Chuanhong Guo
     [not found]                     ` <>
2020-03-11  9:22                       ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \
    --cc=bayi.cheng-NuS5LvNUpcJWk0Htik3J/ \
    --cc=benliang.zhao-NuS5LvNUpcJWk0Htik3J/ \ \ \
    --cc=honghui.zhang-NuS5LvNUpcJWk0Htik3J/ \ \ \ \ \
    --cc=ryder.lee-NuS5LvNUpcJWk0Htik3J/ \ \
    --cc=srv_heupstream-NuS5LvNUpcJWk0Htik3J/ \
    --cc=xiangsheng.hou-NuS5LvNUpcJWk0Htik3J/ \ \
    --subject='Re: [PATCH 3/3] spi: spi-mem: MediaTek: Add SPI NAND Flash interface driver for MediaTek MT7622' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).