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

[PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings

From: tony@atomide.com (Tony Lindgren)
Date: 2012-06-14 16:53:37
Also in: linux-omap

* Mohammed, Afzal [off-list ref] [120614 05:57]:
Hi Tony,

On Thu, Jun 14, 2012 at 17:59:31, Tony Lindgren wrote:
quoted
* Mohammed, Afzal [off-list ref] [120614 05:00]:
quoted
On Thu, Jun 14, 2012 at 17:22:08, Tony Lindgren wrote:
quoted
* Mohammed, Afzal [off-list ref] [120614 03:43]:
quoted
+       t.clk_activation = fclk_offset_ns;
+
This too should be fclk_offset, not fclk_offset_ns.
As gpmc_cs_set_timing convert it to ticks from ns,
shouldn't we put it in ns ? 
Hmm I see, something's wrong though.. Some of these we really
want to specify as ticks instead of ns. Your patch was using
1 tick value as 1 ns value, which won't work. When I changed
it back to what I thought was ticks, it just happened to work
probably because of rounding. That's probably the reason why
some of these have been set directly with gpmc_cs_write_reg
as that sets tick values directly.
For onenand,

fclk_offset = gpmc_ns_to_ticks(fclk_offset_ns);

By using directly fclk_offset_ns, we transfer job of doing
the same to gpmc_cs_set_timings (which does gpmc_ns_to_ticks
over fclk_offset_ns & then do << 25)

Hence passing fclk_offset_ns in effect should be same as,

GPMC_CONFIG1_CLKACTIVATIONTIME(fclk_offset)

If onenand is not working with it, then there is something that
is invisible here.
Yup, you're right, for onenand it should be in ns.
 
Were you able to get it working with the changed value for
usb or onenand ?
Yes seems to work after applying the two patches that I somehow
skipped and with fclk_offset_ns.
 
In case possible, can you check enabling DEBUG and see what
timings are logged
Sounds like the tusb6010 non-ns tick value is the only remaining
issue.

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