[PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings
From: tony@atomide.com (Tony Lindgren)
Date: 2012-06-15 10:45:43
Also in:
linux-omap
* Mohammed, Afzal [off-list ref] [120614 23:20]:
Hi Tony, On Fri, Jun 15, 2012 at 11:12:46, Mohammed, Afzal wrote:quoted
But I am unable to find reason for failure upon using gpmc_ticks_to_ns(1), which seems to me right thing to be used. Let me try to invoke tusb6010 functions in beagle board, observe timings so that at least I will get an idea what is going on here (even though it is guaranteed to crash)Checked simulating on beagle board, I am at total loss to understand why using gpmc_ticks_to_ns(1) has failed for n8x0 clk_activation timings with both values as follows, [1] With t.clk_activation = gpmc_ticks_to_ns(1); GPMC CS4: clk_activation: 1 ticks, 6 ns (was 0 ticks) 6 ns [2] With t.clk_activation = 1; GPMC CS4: clk_activation: 1 ticks, 6 ns (was 0 ticks) 1 ns Last field show in ns the time we are trying to set, and for both cases, 1 ticks are being programmed in register.
Yes tired it again it is working correctly. I must have messed up something yesterday when manually patching the clk_activation, maybe I put the clk_activation value into async timings instead as I was seeing the tick value set to 0 for the sync mode. So looks OK to me, n800 tusb6010 and onenand behave as earlier, also onenand on n900 seems to get detected as earlier. Regards, Tony