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

[Tony Lindgren]

* Mohammed, Afzal <afzal at ti.com> [120614 05:57]:
> Hi Tony,
> 
> On Thu, Jun 14, 2012 at 17:59:31, Tony Lindgren wrote:
> > * Mohammed, Afzal <afzal at ti.com> [120614 05:00]:
> > > On Thu, Jun 14, 2012 at 17:22:08, Tony Lindgren wrote:
> > > > * Mohammed, Afzal <afzal at ti.com> [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