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

[Jon Hunter]

Hi Afzal,

On 06/13/2012 08:05 AM, Mohammed, Afzal wrote:
> Hi Tony,
> 
> On Wed, Jun 13, 2012 at 17:32:09, Tony Lindgren wrote:
>> * Mohammed, Afzal <afzal at ti.com> [120612 22:24]:
>>> Hi Jon,
>>>
>>> On Tue, Jun 12, 2012 at 23:10:01, Hunter, Jon wrote:
> 
>>>> Right but potentially, this could be done by the driver.
>>>
>>> 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.
>>
>> Yeah I also think the GPMC code should handle the L3 timings, and dynamically
>> calculate them for DVFS when L3 frequency changes. Does the GPMC have enough
>> information now to do that?
> 
> Do you mean that gpmc driver should have the capability to calculate peripheral
> timings at runtime based on frequency ?, I am not sure how this can be handled
> by gpmc driver as calculation for different peripherals are done in different
> way, requiring gpmc driver to know about connected peripheral, that would imply
> that gpmc driver would not be peripheral agnostic.

I guess I still don't agree with this. From the gpmc timing point of
view it should not care what device is connected, it just needs to know
the associated timings. Therefore, the gpmc driver just needs the time
associated with the different timings fields in the various GPMC_CONFIGx
registers and then convert to clocks based upon the gpmc fclk. The only
item that is device specific here is the actual timing values and these
can be passed to the driver.

Furthermore, gpmc_cs_set_timings function is completely device agnostic.
Why can we not call this from within the driver? Why does it need to be
called outside the driver?

I am looking for you to prove me wrong about this, but if the only
reason is because we need to fclk rate and timings, then as I have
mentioned before we can pass these to the driver. So I am looking for a
stronger reason than this of why this would not work.

Cheers
Jon