Re: [PATCH] fsl_ifc_nand: Added random output enable cmd

[Boris Brezillon <boris.brezillon@free-electrons.com>]

On Fri, 09 Sep 2016 13:30:41 -0500
Scott Wood <oss@buserror.net> wrote:

> On Fri, 2016-09-09 at 09:40 +0200, Boris Brezillon wrote:
> > > >   
> 
> 
> > On Thu, 08 Sep 2016 22:00:10 -0500
> > Scott Wood <oss@buserror.net> wrote:
> >   
> > > 
> > > On Thu, 2016-09-08 at 07:57 +0200, Boris Brezillon wrote:  
> > > > 
> > > > On Wed, 07 Sep 2016 18:18:59 -0500
> > > > Scott Wood <oss@buserror.net> wrote:
> > > >   
> > > > > 
> > > > > A generic "send_op" might
> > > > > work, though I'm curious about the details of how nand_op gets
> > > > > encoded,
> > > > > and am
> > > > > worried that it might still result in NAND drivers interpreting
> > > > > specific
> > > > > commands rather than passing things through in a generic way (and then
> > > > > things
> > > > > can break if common code sends something new).    
> > > > If drivers end up doing that, this means we failed providing an
> > > > interface that is suitable for everyone.
> > > > But, from what I've seen in other drivers, it's usually just about
> > > > setting the first and second cmd cyles, specifying the address cycles
> > > > (and the number of cycles) and then the amount of data to transfer +
> > > > the direction.    
> > > Timing is one area that could be problematic.  This patch is an example of
> > > a
> > > situation where different timing was used for a particular command.  It
> > > seems
> > > that RNDOUT doesn't use the R/B pin -- how would a generic send_op
> > > implementation know whether it can use R/B to determine when to start the
> > > I/O
> > > transfer?  
> > Well, the plan was to specify in the nand operation whether it should
> > wait for the chip to be ready or not.  
> 
> OK.  Is there a more detailed description of send_op ready yet?

I started something more than a year ago [1], but did not find the time
to finish the implementation. The plan was to rework the entire NAND
framework, not only the way we send NAND operations/commands, so this
branch contains much more than just the ->send_op() concept. But you
can see the nand_operation struct here [2].

Now, I realize that this attempt to rework the whole framework at once
was not doable, but I can probably provide a PoC introducing the
->send_op() method and nand_operation struct, and implement
->send_op() in the sunxi driver.

This being said, my main concern is the introduction of yet another way
to do things. The NAND framework is already quite complex, and if we
introduce this ->send_op() method, I'd like it to completely replace
the ->cmdfunc() instead of keeping both around until all
implementations decide to switch to the new approach.

Note that a default ->send_op() based around ->cmd_ctrl()
and ->{read/write}_buf() can easily be implemented.

[1]https://github.com/bbrezillon/linux-sunxi/tree/nand-core-rework-v2
[2]https://github.com/bbrezillon/linux-sunxi/blob/nand-core-rework-v2/include/linux/mtd/nand2.h#L41