[RFC] Support custom timings for NAND chips

[Boris Brezillon]

Hi Roy,

Sorry for the latency.

On Tue, 16 Jun 2015 11:45:01 +0200
Roy Spliet <r.spliet at ultimaker.com> wrote:

> Hello,
> 
> Following is a fairly simple set of three patches that both implement and
> demonstrate the use of custom timings for chip. This follows from the
> requirement to support the Hynix H27UBG8T2BTR-BC, as shipped by Olimex on
> their Allwinner-based ARM-boards.
> 
> I motivate my chosen approach as follows:
> 1) Requirement. The NAND chip is being used in the wild, and using the only
>    supported ONFI timing (0) is significantly degrading performance.
> 2) Simplicity. The three patches are fairly straightforward, and do what they
>    should do without compromise. Alternative approaches like sticking timings
>    in the DT makes it more difficult for distribution to ship universal
>    kernels and DTBs, because it's a NAND chip property and not a board
>    property.

AFAICT, it's even worst than that. I tried to boot this Olimex board
you are talking about, and it seems using ONFI timing mode 0 makes the
NAND completely unreliable. I'm not sure exactly why this happens but
here is what I suspect: the NAND is supposed to work in EDO mode, but
EDO is only active when tRC is lower than 30ns, which is not the case in
mode 0. ITOH, we cannot switch to mode 4 (which, according to the NAND
timings described in the datasheet, is the most appropriate) because
tADL is not met in this mode (tADL = 200ns, while mode 4 expect 70ns).

> 
> I send this out now (asap), because the only legacy that requires a change is
> sunxi-nand. The longer we wait, the harder it gets. Don't let that stop you
> from doing a proper review job! :-)
> Comments? Ideas?

Hm, maybe we should store nand timings directly in the nand_chip
struct, and let the core code fill it with ONFI values (when ONFI is
available) so that controller drivers do not have to do the ONFI mode
to timing struct dance.

For NAND specific timings like the ones you need for the
H27UBG8T2BTR-BC chip, maybe we could keep them in a vendor specific file
instead of defining them in the nand_ids.c file.
Also, I'm not sure whether we should define them with a new struct
nand_sdr_timings instance, or just provide a function adjusting some
fields based on the provided default ONFI timing mode.

Brian, any suggestion?

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com