From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Thu, 14 Jun 2012 09:53:37 -0700 Subject: [PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings In-Reply-To: References: <20120613113217.GK12766@atomide.com> <20120613115445.GM12766@atomide.com> <20120614101901.GI12766@atomide.com> <20120614115207.GL12766@atomide.com> <20120614122930.GM12766@atomide.com> Message-ID: <20120614165337.GO12766@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Mohammed, Afzal [120614 05:57]: > Hi Tony, > > On Thu, Jun 14, 2012 at 17:59:31, Tony Lindgren wrote: > > * Mohammed, Afzal [120614 05:00]: > > > On Thu, Jun 14, 2012 at 17:22:08, Tony Lindgren wrote: > > > > * Mohammed, Afzal [120614 03:43]: > > > > > + 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