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

Hi Jon,

On Fri, Jun 15, 2012 at 02:21:50, Hunter, Jon wrote:

On 06/14/2012 01:17 AM, Mohammed, Afzal wrote:

quoted

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.

quoted

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