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

Scott Wood
2015-06-08T20:24:35Z

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@gmail.com>
> > >
> > > Signed-off-by: Roy Spliet <r.spliet@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