Hi Jon, On Fri, Jun 15, 2012 at 02:21:50, Hunter, Jon wrote: > On 06/14/2012 01:17 AM, Mohammed, Afzal wrote: > > 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. > > Absolutely! No argument there. > > > 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 > > I understand, but that is not my point. My point is that timings should > be provided in nanoseconds for all devices. Then the gpmc driver can > query the gpmc fclk and convert to gpmc cycles. This way the gpmc driver > will not care what device is connected in terms of the timings and can > convert them. But the way gpmc clock period has its effect on timings required for different peripherals is different, i.e. input timing to be provided for gpmc_cs_set_timings depends on gpmc clk & it's effect varies with the peripheral Even for the same peripheral, directly scaling timings for a different frequency may not work 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
