Hi Tony,

Could not respond you earlier as was sick

On Fri, Jul 06, 2012 at 17:35:33, Tony Lindgren wrote:

* Mohammed, Afzal [off-list ref] [120705 07:56]:

quoted

On Thu, Jul 05, 2012 at 16:25:35, Tony Lindgren wrote:

quoted

Presently bigger issue that I am facing w.r.t driver conversion is the
requirement of peripheral specific gpmc timing calculation before probe.
I believe currently in mainline runtime gpmc clock changes are not
handled

Hmm I don't follow, why can't the timings be set during the peripheral
specific driver probe?

My viewpoint while making the above comment was with gpmc driver
series that was posted, in that it was required to do peripheral specific
timings calculation before probe. With your suggested peripheral specific
driver for the purpose of handling retime, it is not a problem, a
solution on how to integrate it has to be found though.

quoted

quoted

The peripheral driver can register it's retime function with gpmc and
get a cookie back that allows getting the DT provided timings from gpmc.
And after that the initial timings can be set.

If timings peripheral timings can be fully contained in driver, should
we try to pass the same timings translated in terms of gpmc timings
through DT ?, and how do we get equivalent gpmc timings to update DT,
manually calculate similar to platform init code ?, or I misunderstood
you

Well yes the timings should be passed via devicetree in a gpmc specific

I assume with the above, you were referring to peripherals that does not
have retime function.

format. But the peripheral specific retime function still needs to be
also registered for peripherals that need it.

For the peripherals requiring retime, we cannot (as otherwise whatever
retime does would have to be manually done based on the knowledge of
boot time gpmc clock period to calculate gpmc timings to be fed to DT)
pass gpmc timings via device tree, right ?

Regards
Afzal