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

[jon-hunter@ti.com (Jon Hunter)]

Hi Afzal,

On 06/14/2012 01:17 AM, Mohammed, Afzal wrote:
> 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.

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.

What does make this a bit more difficult is the function
gpmc_round_ns_to_ticks(). It appears to convert nanoseconds to ticks and
back to nanoseconds. I am guessing to account for some rounding error. I
am curious what impact this function is having on the timing. Ideally
this should be handle in gpmc_cs_set_timings().

Cheers
Jon