[PATCH v2 2/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration

[Mohammed, Afzal]

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