Hi Afzal, On 05/08/2012 01:24 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Mon, May 07, 2012 at 21:42:35, Hunter, Jon wrote: > >>> Clk_prd is a platform data passed to the driver, so platform code >>> updates it, where else can it be done ? >> >> The point is that you can pass what ever you like. You do not need to >> pass the frequency you can pass the clock handle instead. > > As clk rate is required in platform code for timing calculation, and > already available, period was passed Sure. >> >> What happens it the clk_get() of the gpmc_l3_clk fails during the init? > > Thanks for bringing this point, invalid clk_prd has to be handled by driver. > >> >> In fact if you migrate to runtime pm then we should not have the clk_get >> in the gpmc_init any more. > > Even if converted to RPM, to get clk rate, clk_get has to be done > somewhere, right ? Yes exactly. However, you could now do this in the driver itself like the probe function. Or may be just pass the frequency of the gpmc fclk to the driver and let the driver convert to the period. No reason we need to convert to the period outside of the driver. Hence, we can keep the function to do the conversion static in the driver and don't need to expose externally. Jon -- 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