* Mohammed, Afzal [off-list ref] [120710 03:09]:

Hi Tony,

On Tue, Jul 10, 2012 at 15:15:38, Tony Lindgren wrote:

quoted

* Mohammed, Afzal [off-list ref] [120709 23:24]:

quoted

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

quoted

quoted

quoted

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 ?

We can still do it when the connected peripheral probe registers with
gpmc.

We can, but would it be feasible practically ?, gpmc timings to update in
DT for a such a peripheral (requiring retime) can be found out only by
manual calculation similar to the way done in retime function (based on
peripheral's timings and boot time gpmc clock period), correct ?, Also
wouldn't this make it necessary to know gpmc clock period at boot time
for properly updating gpmc timing entry in DT ?

The gpmc clock period can be returned to the connected peripheral when
it's registering. Well basically we can call the retime function upon
registering and pass the gpmc clock period.
 

And in this case, we are going to register retime function, so instead of
relying on DT to provide gpmc timings for such a peripheral, won't it
be better to make use of retime that is already registered ?

No we need to pass the timings from device tree as they may be different
for similar boards. For example, different level shifters used on
similar boards may affect the timings, although the retime function
can be the same.

Regards,

Tony