[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