Scott Wood a écrit : > 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). Are there 4K chip that are not CE-don't-care ?
Also I think it depends how the bus are connected (shared with other device) and the controller. Matthieu _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
