ARM: kirkwood: Fix chip-delay for GoFlex Net

Hi,

This fixes "Too few good blocks within range" issues on GoFlex Net by setting chip-delay to 40. I've been using this patch on my device for quite a while now (accessing uboot vars is not possible without it). The basic problem was discussed at
http://forum.doozan.com/read.php?2,7451 and I think this fix should go mainstream.

Greetings

Eric Hutter

---
  arch/arm/boot/dts/kirkwood-goflexnet.dts | 1 +
  1 file changed, 1 insertion(+)

b/arch/arm/boot/dts/kirkwood-goflexnet.dts
index bd83b8f..c3573be 100644

@@ -77,6 +77,7 @@
          };
 
          nand at 3000000 {
+            chip-delay = <40>;
              status = "okay";
 
              partition at 0 {

1.8.1.4

Hi Eric

Its a problem seen by a couple of other boards as well, e.g. dns320 and dns325.

The MTD core default of 20us is too small for modern NAND flash.. This number is based on the chip's datahseet, it should be the longest non-programming command BUSY interval. Eric, if you haven't already, it is worth a quick check of the datasheet to verify. Eg the Micron flash on my Kirkwood system should be 70us.

u-boot can sometimes get away with a smaller value because it only uses a limited set of commands.

It is on my TODO list to implement ONFI READY/BUSY# pin support in the orion-nand driver via a GPIO - could other systems make use of this as well?

Regards,
Jason

Nice catch! I'll include this in the next round of fixes I push.

thx,

Jason.

[1] (see below)

Applied to mvebu/fixes.

I cleaned up the commit message to remove the conversational pieces. In the future, you can place this type of info here [1]. When patches are applied from an email message, everything after the Subject line and before the '---' becomes the commit message.

I've also Cc'd this to stable for v3.6.x and newer.

thx,

Jason.