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

[Matthieu CASTET]

LiuShuo a écrit :
> 于 2011年08月23日 00:19, Scott Wood 写道:
>> On 08/22/2011 11:13 AM, Matthieu CASTET wrote:
>>> Scott Wood a écrit :
>>>> 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