[PATCH] ARM: kirkwood: Increase NAND chip-delay for DNS-320

Andrew Lunn andrew at lunn.ch
Tue Oct 30 02:02:26 EDT 2012

> >I'm currently downloading the GPL sources from dlink. If the kernel
> >sources are included, we can see how dlink sets this. If its also 35,
> >then there is no argument.
> Rummaging myself, my best guess is:
> linux-
> 173:    this->chip_delay = 30;
> u-boot-1.1.4/board/mv_feroceon/USP/mv_nand.c
> 68: nand->chip_delay = 30;
> However, this is too fast for my NAS when using a mainline kernel.
> 31usecs seems to work though. It's probably worth noting that the
> original firmware wasn't without it's problems on this particular
> board---I couldn't get it to reflash the NAND with a new firmware
> image. It could certainly read the NAND though.
> This chip_delay value seems to be there in both the DNS320 and
> DNS325 GPL source. Maybe increasing chip_delay for both would be
> safest.

Yep. Please could you submit a new patch for dnskw.dtsi.

I guess you are not the only person with problems with 30, so 35 seems

Do you have any idea how much this affects performance? It might not
be worth the effort to probe the chip and set the timing, if its only
a couple of % difference.


More information about the linux-arm-kernel mailing list