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

[Scott Wood <oss@buserror.net>]

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?

> > A bigger problem with separating the command from the I/O is the R/B pin.
> >  If
> > the NAND chip asserts R/B when another (non-NAND) device's chipselect is
> > asserted, then it can corrupt that chip's activity.  We'd be undoing the
> > fix
> > in commit 476459a6cf46d20e ("mtd: eLBC NAND: use recommended command
> > sequences").
> The ->send_op() method we're discussing would solve this problem, right?

Yes.

-Scott