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

[Mohammed, Afzal]

Hi Jon,

On Wed, Jun 13, 2012 at 20:21:50, Hunter, Jon wrote:

> > I do not think it is practically possible. Please see timing calculations
> > in arch/arm/mach-omap2/gpmc-*, the way it is done for different
> > peripherals are different, and we cannot expect gpmc driver to do those as
> > that would require gpmc driver being aware of type of peripheral connected.
> > 
> > And all those gpmc-* timing calculation needs to be done before driver
> > is ready, they rely on functions like gpmc_get_fclk_rate(), which in turn
> > requires the clk rate to be available before driver is probed.
> 
> So I see that the various gpmc-*.c files have some form of _retime()
> function. However, at the end of the day they all call
> gpmc_cs_set_timings() to convert time into gpmc clocks. Converting time
> to gpmc clocks is completely independent of the actual device and so
> this can be performed by the driver. We just need to populate the
> gpmc_timings struct and pass to the driver to convert to clocks and
> program into the registers.

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.

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

Regards
Afzal