于 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.
Even if we use SW_ECC, we always get lots of weird '0xFF's between 1st
2k and 2nd 2k data.
They will cover the data in the head of 2nd 2K.
-------------------------------------------------------------------------------------
| xxxxxx ... 1st 2k xxxxxxx ... | ff ff ff ... ff xxxxxx 2nd 2k xxxxxxx |
-------------------------------------------------------------------------------------
It is worse to write 4k data with once command issuing. It can't write
the 2nd data correctly.
-Liu Shuo
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
