Hi Jon, On Wed, Jun 13, 2012 at 20:21:50, Hunter, Jon wrote: > > 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. > > So I see that the various gpmc-*.c files have some form of _retime() > function. However, at the end of the day they all call > gpmc_cs_set_timings() to convert time into gpmc clocks. Converting time > to gpmc clocks is completely independent of the actual device and so > this can be performed by the driver. We just need to populate the > gpmc_timings struct and pass to the driver to convert to clocks and > program into the registers. gpmc_cs_set_timings() does currently convert time to clock cycles required, and this gpmc driver have the capability to do it. What I was saying is a different issue, input to gpmc_cs_set_timings, which is time sometimes in turn is a function of time or to be exact depends on gpmc clock period also. So timings provided to gpmc_cs_set_timings for a particular frequency may not hold good for another frequency, unless we change the input time to gpmc_cs_set_timings based on gpmc clock. If you see gpmc-* files, many a times, they need to know value of gpmc fclk, to calculate the input time to be fed for gpmc_cs_set_timings 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
