[U-Boot] [RFC 02/11] mtd/nand: add ONFI timing mode to nand_timings converter

[Scott Wood]

On Mon, 2015-06-08 at 10:11 +0200, Roy Spliet wrote:
> Hello Scott et al.,
> 
> Op 06-06-15 om 00:02 schreef Scott Wood:
> > On Fri, 2015-06-05 at 13:52 +0200, Roy Spliet wrote:
> > > From: yassin <yassinjaffer at gmail.com>
> > > 
> > > Signed-off-by: Roy Spliet <r.spliet at ultimaker.com>
> > > ---
> > >  drivers/mtd/nand/Makefile       |   2 +-
> > >  drivers/mtd/nand/nand_timings.c | 252 
> > > ++++++++++++++++++++++++++++++++++++++++
> > >  include/linux/mtd/nand.h        |   3 +
> > >  3 files changed, 256 insertions(+), 1 deletion(-)
> > >  create mode 100644 drivers/mtd/nand/nand_timings.c
> > This code comes from Linux and yet I see no acknowledgement of 
> > that, 
> > much less a statement of which version of Linux this was pulled 
> > from.
> Correct, my apologies as I should have clarified that "work by Boris 
> Brezillon" does not
> mean "upsteam work". The code comes from Boris' github tree[1] and 
> contains work
> that was not yet brought upstream, yet is required for NAND on sunxi 
> to work.
> > It would probably be better to handle this as part of a general 
> > sync 
> > with the Linux mtd code.
> Ideally yes, but. In upstream Linux MTD we have a few issues to 
> address as shown
> by Boris' patch-set, most importantly:
> - NAND chip timings (patch 1 to 3)

Patches 1-3 are already in Linux (if there are subtle differences 
needed those should be followup patches, with an explanation of why it 
needs to differ from Linux), except that patch 3 for some reason has 
"onfi_timing_mode_ds" where Linux has "onfi_timing_mode_default".

I will try to do a sync soon.

> U-Boot has the additional challenge
> - Partitioning is not done the upstream way, but rather in/around 
> cmd_mtdparts
> 
> We started discussion on these topics in the #mtd IRC channel 
> (OFTC), and several ideas
> have come up. The way I see it these issues can currently either be 
> addressed by
> bolting/duct-taping/tie-wrapping more layers of indirection on top 
> of upstream MTD
> framework, but really I feel that it might require a bit more of a 
> structural approach
> that may or may not break existing drivers.
> The code I posted as RFC is functional. If you wish to steer towards 
> an MTD sync-up, I
> highly suggest first getting these issues tackled, and then making 
> sure that we extend
> the U-boot side of MTD with OF support for everything. This 
> trajectory should include
> deprecating the current implementation of cmd_mtdparts and hook that 
> command up
> to the "new" upstream way. In other words: now is probably not the 
> right moment.

I don't see why those things are a prerequisite for syncing MTD from 
Linux to U-Boot.  If there are further changes in Linux after a sync 
that we want to bring in, we can sync again and it will be easier 
because the sync will contain fewer changes.

-Scott