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

Hi Jon,

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

quoted

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