Hi Tony, On Tue, Jul 10, 2012 at 15:15:38, Tony Lindgren wrote: > * Mohammed, Afzal <afzal@xxxxxx> [120709 23:24]: > > On Fri, Jul 06, 2012 at 17:35:33, Tony Lindgren wrote: > > > 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 ? 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 ? Regards Afzal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
