Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip

LiuShuo a écrit :

于 2011年08月23日 00:19, Scott Wood 写道:

quoted

On 08/22/2011 11:13 AM, Matthieu CASTET wrote:

quoted

Scott Wood a écrit :

quoted

To eliminate it we'd need to do an extra data transfer without reissuing
the command, which Shuo was unable to get to work.

That's weird because our controller seems quite flexible [1].

Something like that should work ?

             out_be32(&lbc->fir,
                      (FIR_OP_CM2<<  FIR_OP0_SHIFT) |
                      (FIR_OP_CA<<  FIR_OP1_SHIFT) |
                      (FIR_OP_PA<<  FIR_OP2_SHIFT) |
                      (FIR_OP_WB<<  FIR_OP3_SHIFT));
refill FCM buffer with next 2k data

             out_be32(&lbc->fir,
                      (FIR_OP_WB<<  FIR_OP3_SHIFT) |
                      (FIR_OP_CM3<<  FIR_OP4_SHIFT) |
                      (FIR_OP_CW1<<  FIR_OP5_SHIFT) |
                      (FIR_OP_RS<<  FIR_OP6_SHIFT));

Something like that is what I originally suggested, but Shuo said it
didn't work (even in theory, it requires a CE-don't-care NAND chip,
since bus atomicity is broken).

Shuo, what specifically did you try, and what did you see happen?

-Scott

First, if we want to read 4K data with once command issuing, we can't 
use HW_ECC.

Yes, but as ivan said doesn't the cost of 2 read isn't bigger than software ecc ?

Even if we use SW_ECC, we always get lots of weird '0xFF's between 1st 
2k and 2nd 2k data.

Did you understand where those 0xff comes (what's the size of them. Doesn't the
controller try to insert spare aera ?)

Could you detail the sequence you used ?

Matthieu