Thread (50 messages) 50 messages, 3 authors, 2012-06-15
STALE5146d

[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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help