* Mohammed, Afzal [off-list ref] [120614 03:15]:

Hi Tony,

On Wed, Jun 13, 2012 at 17:28:33, Mohammed, Afzal wrote:

quoted

On Wed, Jun 13, 2012 at 17:24:45, Tony Lindgren wrote:

quoted

quoted

If there's a chance it causing file system corruption, we should
test it carefully on the boards before applying. If that's done,
then there's probably no need for warnings. It's safer to disable
NAND for untested boards if there's a chance of breaking the timings.

Actually this patch breaks at least DMA on tusb6010 on n8x0. That's
a MUSB hardware in a wrapper connected to GPMC that's very picky with
the timings.

Got any hints what should be done with the cycle2cycle stuff for
tusb6010?

Not as of now, let me try to find out.

Probably with the below patch [1], we can get values set by bootloader &
calculate back value to entered in Kernel, of course that may not work
if tusb6010 works with different gpmc i/p frequency.

Well I took a look at the values, and it seems the only difference is the
static GPMC_CONFIG1_CLKACTIVATIONTIME(1) that your patch now overwrites 0.

Tony