linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/2] staging: mtd: Support for GigaDevice SPI NAND flash
@ 2014-11-06 15:51 Ionela Voinescu
  2014-11-06 15:51 ` [PATCH 1/2] staging: mtd: GigaDevice 4Gb SPI NAND driver Ionela Voinescu
                   ` (2 more replies)
  0 siblings, 3 replies; 18+ messages in thread
From: Ionela Voinescu @ 2014-11-06 15:51 UTC (permalink / raw)
  To: computersforpeace, gregkh, linux-mtd
  Cc: Ionela Voinescu, abrestic, dehrenberg, ezequiel.garcia,
	sourav.poddar, james.hartley

Hi, 

These patches add support for GigaDevice 4Gb SPI NAND flash.
This is an initial version, adding it to staging, as there is no existing 
framework for SPI NAND as there is for SPI NOR in MTD.

Therefore, I want to start an early discussion about this in order to find 
the best way to integrate it. I am at the beginning regarding both upstreaming 
and understanding all of the MTD layer, so your comments and ideas are 
welcomed.

I've structured this driver similar to the existing Micron SPI NAND 
(mt29f_spinand), in order to make it easier to understand the common code.
I know there is an atempt to add support for a generic SPI NAND based 
framework from Sourav Poddar but that never got merged, and it would be 
a valid option to consider.

http://lists.infradead.org/pipermail/linux-mtd/2013-July/047373.html

This initial version does not implement all the functionality and I will 
add to it once we decide on a structure. This is based on linux-next. 

Thank you and I welcome all comments,
Ionela. 

Ionela Voinescu (2):
  staging: mtd: GigaDevice 4Gb SPI NAND driver
  Documentation: staging: mtd: Binding document for GigaDevice SPI NAND

 .../bindings/staging/mtd/gd5f_spinand.txt          |   13 +
 drivers/staging/Kconfig                            |    2 +
 drivers/staging/Makefile                           |    1 +
 drivers/staging/gd5f_spinand/Kconfig               |   15 +
 drivers/staging/gd5f_spinand/Makefile              |    1 +
 drivers/staging/gd5f_spinand/gd5f_spinand.c        | 1056 ++++++++++++++++++++
 drivers/staging/gd5f_spinand/gd5f_spinand.h        |  182 ++++
 7 files changed, 1270 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/staging/mtd/gd5f_spinand.txt
 create mode 100644 drivers/staging/gd5f_spinand/Kconfig
 create mode 100644 drivers/staging/gd5f_spinand/Makefile
 create mode 100644 drivers/staging/gd5f_spinand/gd5f_spinand.c
 create mode 100644 drivers/staging/gd5f_spinand/gd5f_spinand.h

-- 
1.7.9.5

^ permalink raw reply	[flat|nested] 18+ messages in thread
* [PATCH 0/2] staging: mtd: Support for GigaDevice SPI NAND flash
@ 2014-11-20  8:39 bpqw
  2014-11-20 13:18 ` Ezequiel Garcia
  0 siblings, 1 reply; 18+ messages in thread
From: bpqw @ 2014-11-20  8:39 UTC (permalink / raw)
  To: Brian Norris, arnaud.mouiche@invoxia.com,
	linux-mtd@lists.infradead.org
  Cc: ezequiel.garcia@imgtec.com, ionela.voinescu@imgtec.com

Hi Brian, Arnaud:
> If we are going to a specific spinand framework, my advice would be to 
> read again the spi nor framework carefully first, and do something 
> similar (especially for latests work on quad spi)

I think above idea is good. 
SPI NAND interface and command protocol are similar with SPI NOR, we can 
create a SPI NAND folder with similar framework with SPI NOR. But need to duplicate 
nand_bbt and nand_bch code into this folder due to SPI NAND still need BBM and ECC.
How do you think?

I ever compared the SPI NAND command protocol with different vendor, result is same
with Ionela's answer.  

" As far as I've seen from the datasheets I have available (SPI NAND
GigaDevice 1Gb/2Gb/4Gb, Micron 1Gb/2Gb/4Gb), the command sequencing
is the same for read/write/erase operations (read: enable ECC, read to cache,
wait, read from cache, check for errors, disable ECC; write: enable ECC,
write enable, program load, program execute, wait, verify, disable ECC;
erase: write enable, erase block, verify).

Regarding the stream of bytes for each command, the problematic
commands are the read from cache ones (read, fast read, read x2,
read x4, read dual read quad) that have different command format
(additional dummy bytes, a plane select bit to be set).
Other differences are in the structure of the protection and status registers
(some of them use more ECC and protection bits according to the size
of the chip). Also, each has a different ECC layout "

If you need my detail comparison table, please let me know.

I already set up platform to support SPI NAND now, if you think the framework I mentioned 
above is reasonable, I can start to work on this.

Thanks

Qi Wang

^ permalink raw reply	[flat|nested] 18+ messages in thread
[parent not found: <mailman.22397.1416508326.22890.linux-mtd@lists.infradead.org>]

end of thread, other threads:[~2014-11-25 17:01 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-06 15:51 [PATCH 0/2] staging: mtd: Support for GigaDevice SPI NAND flash Ionela Voinescu
2014-11-06 15:51 ` [PATCH 1/2] staging: mtd: GigaDevice 4Gb SPI NAND driver Ionela Voinescu
2014-11-06 15:51 ` [PATCH 2/2] Documentation: staging: mtd: Binding document for GigaDevice SPI NAND Ionela Voinescu
2014-11-06 16:05 ` [PATCH 0/2] staging: mtd: Support for GigaDevice SPI NAND flash Greg KH
2014-11-06 17:32   ` Ionela Voinescu
2014-11-06 17:44     ` Greg KH
2014-11-06 18:03       ` Ionela Voinescu
2014-11-06 18:17         ` Ezequiel Garcia
2014-11-06 19:20           ` Brian Norris
2014-11-07 13:00             ` Ionela Voinescu
2014-11-10  9:00             ` arnaud.mouiche
  -- strict thread matches above, loose matches on Subject: below --
2014-11-20  8:39 bpqw
2014-11-20 13:18 ` Ezequiel Garcia
2014-11-25  7:02   ` bpqw
2014-11-25 16:59     ` Ezequiel Garcia
     [not found] <mailman.22397.1416508326.22890.linux-mtd@lists.infradead.org>
2014-11-21  1:16 ` Qi Wang 王起 (qiwang)
2014-11-21  9:24   ` arnaud.mouiche
2014-11-21 11:51   ` Ezequiel Garcia

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