Hi Jon, On Thu, Jun 21, 2012 at 03:41:39, Hunter, Jon wrote: > Ok, I see your point. So today the _set_async_mode() is really doing two > things ... > > 1. It is calculating the timings > 2. Programming the timings and setting async mode. > > I think that it would be best if we were to make _set_async_mode() into > two functions, for example ... > > 1. omap2_onenand_get_async_timings() > 2. omap2_onenand_set_async_timings() > > Where the omap2_onenand_get_async_timings() calculates the timings and > can be used in both legacy mode and with the driver. Then > omap2_onenand_set_sync_timings() is just used in the legacy mode where > we don't have the driver to configure the chip-select. > > Do you think that could work? > > We could also do the same for omap2_onenand_set_sync_mode(). Seems it should work Not sure whether the best time to do such kind of refactoring is at the time of cleaning up / generalizing timing calculation, one reason to think that way being removal of legacy mode once driver migration is completed. Goal for this series was to do the minimal of changes, without creating any disruptive changes to prepare for gpmc driver series so that both interfaces would work. Either way I will go ahead and make change as per your suggestions, seems at least there is one advantage; w.r.t bringing setting bool type time settings to gpmc_cs_set_timings (even though may not be necessary for this change, it will certainly simplify it) and make it part of driver preparation series and this will help us discover if any board depends on these kinds of settings unknowingly with the preparation series itself rather than hunting for it in driver series 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
