[PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD

[Mohammed, Afzal]

Hi Jon,

On Fri, Jun 15, 2012 at 02:21:50, Hunter, Jon wrote:
> On 06/14/2012 01:17 AM, Mohammed, Afzal wrote:

> > gpmc_cs_set_timings() does currently convert time to clock cycles required,
> > and this gpmc driver have the capability to do it.
> > 
> > What I was saying is a different issue, input to gpmc_cs_set_timings, which
> > is time sometimes in turn is a function of time or to be exact depends on
> > gpmc clock period also. So timings provided to gpmc_cs_set_timings for a
> > particular frequency may not hold good for another frequency, unless we
> > change the input time to gpmc_cs_set_timings based on gpmc clock.
> 
> Absolutely! No argument there.
> 
> > If you see gpmc-* files, many a times, they need to know value of gpmc fclk,
> > to calculate the input time to be fed for gpmc_cs_set_timings
> 
> I understand, but that is not my point. My point is that timings should
> be provided in nanoseconds for all devices. Then the gpmc driver can
> query the gpmc fclk and convert to gpmc cycles. This way the gpmc driver
> will not care what device is connected in terms of the timings and can
> convert them.

But the way gpmc clock period has its effect on timings required for
different peripherals is different, i.e. input timing to be provided for
gpmc_cs_set_timings depends on gpmc clk & it's effect varies with the
peripheral

Even for the same peripheral, directly scaling timings for a different
frequency may not work

Regards
Afzal