[U-Boot] Issue about support spi-nand in u-boot

[Peter Pan 潘栋 (peterpandong)]

Resend the mail.

On 29 May 2015 at 19:53, Jagan Teki <jteki at openedev.com> wrote
> On 29 May 2015 at 11:42, Peter Pan 潘栋 (peterpandong)
> <peterpandong at micron.com> wrote:
> > Hi Jagan
> >
> > I looked through your code[1] about support Linux spi-nor framework
> in u-boot.
> > It is really great.
> 
> I'm bit concern about the spi-flash framework and planning to make
> generic
> thanks for your response on this.
> 
> >
> > I'm working on spi-nand in u-boot now. And I met some issues. Maybe
> we
> > can have a discussion.
> >   1. Currently spi_flash struct is tied with spi nor, as spi nand is
> also
> >      a kind of spi flash. I think we should make spi_flash struct
> shareable.
> >   2. In Linux, we can use parameter .tx_nbits and .rx_nbits in
> spi_transfer
> >      struct to tell controller driver to use 1bit, 2bits or 4bits to
> transfer
> >      data. But I didn't find a way to do it in u-boot. Maybe we can
> add some
> >      transfer flags to do this.
> 
> We handle these on flash code it self, by assigning SINGLE, DUAL and
> QUAD commands
> from the controller flags. See tha drivers/mtd/spi/sf-probe.c if you
> still unclear let me know
> will discuss more.

You mean that currently spi nor code assign SINGLE, DUAL or QUAD command
to spi nor specified controller, then controller decided how many pins
are used for data transfer by decode the command?

At present, I think there are few spi nand specified controller. I'm using
a generic spi controller. Now I handle all the things(including pin numbers)
in the spi nand code, spi controller just do "data" transfer(no difference
between command and data). That why I need a flag to do it.

Also, We can let spi controller driver to handle the things. Controller
driver treat the first byte of the transfer with SPI_XFER_BEGIN flag as
command. By decode the command do the right transfer.

Which method do you think is more appropriate? 

> 
> >   3. Should we use spi nand via "sf" command set or create another
> command set?
> >
> 
> question 1, 3 - Below are my understanding till now about the
> implementation, just grab
> these probably will discuss more.
> 
> I'm also thinking that the spi-flash.h should be common to nor and
> nand and from flash
> code level there should be a generic code that intern divide the
> spi-nor and spi-nand.
> 
> Let's say cmd_sf will take nor or nand ops from user and this will
> intern call flash code in
> drivers/mtd like drivers/mtd/spi/spi-nor-flash.c in my new code. So
> spi-nor-flash.c will become
> spi-flash.c this have capability to handle spi-nor and spi-nand. Each
> spi-nor and spi-nand have
> separate in-built cores(spi-nor.c and spi-nand.c).

I also prefer share cmd_sf. And If do so, maybe we need add a sf command
to do oob ops for nand, right?

> 
> And then spi-nor.c will again transition to general spi drivers -
> drivers/spi/ and few flash specific
> spi drivers(not implemented yet) those will be drivers/mtd/spi/nor.
> For spi-nand.c will again transition
> to general nand drivers - drivers/mtd/nand/ and few flash specific
> nand drivers (if they) those will be
> drivers/mtd/spi/nand.
> 
> common/cmd_sf.c -- handle both spi-nor/nand
> include/spi_flash.c -- handle spi-flash stuff both for spi-nor/nand
> 
> drivers/mtd/spi/ -- for spi flash code
> 
> drivers/mtd/spi/nor -- for spi-nor code
> drivers/mtd/spi/nor.c -- for spi-nor core
> drivers/mtd/spi/zynq_qspi.c -- zynq spi-nor controller (thought it's
> (q)spi controller, but particularly
>                              implemented for spi-nor based
> functionalists)
> include/spi-nor.h -- header file for spi-nor core
> 
> drivers/mtd/spi/nand -- for spi-nand code
> drivers/mtd/spi/nand.c -- for spi-nand core
> drivers/mtd/spi/xxx_snand.c -- xxx spi-nand controller (thought it's
> nand controller, but particularly implemented for spi-nand based
> functionalists)
> include/spi-nand.h -- header file for spi-nand core
> 

This is really a good structure. I'm a big fan of it.

> > Any suggestion is appreciated.
> >
> > Another question, do you have any schedule about when to merge spi-
> nor framework?
> 
> Probably in the coming release, once this is in few of the driver in
> drivers/spi need to write
> back to spi-nor layer (those are full flash specific)

I really appreciate your work. I would help you on it if you need.

> 
> >
> > [1] http://git.denx.de/?p=u-boot/u-boot-
> spi.git;a=shortlog;h=refs/heads/spi-nor
> 
> thanks!
> --
> Jagan Teki,
> Openedev.