[PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
afzal at ti.com
Fri Jun 15 06:40:45 EDT 2012
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
Even for the same peripheral, directly scaling timings for a different
frequency may not work
More information about the linux-arm-kernel