* Mohammed, Afzal <af...@ti.com> [120614 02:46]: > Hi Tony, > > On Thu, Jun 14, 2012 at 14:59:57, Tony Lindgren wrote: > > * Afzal Mohammed <af...@ti.com> [120611 07:21]: > > > > + GPMC_SET_ONE(GPMC_CS_CONFIG6, 0, 3, bus_turnaround); > > > + GPMC_SET_ONE(GPMC_CS_CONFIG6, 8, 11, cycle2cycle_delay); > > > + > > > + GPMC_SET_ONE(GPMC_CS_CONFIG1, 18, 19, wait_monitoring); > > > + GPMC_SET_ONE(GPMC_CS_CONFIG1, 25, 26, clk_activation); > > > + > > > > Thinking about this, the CONFIG1 bits have been set with > > gpmc_cs_write_reg because these are part of the static configuration > > and do not need to be dynamically calculated as they are tick based. > > For example, tusb6010 sets GPMC_CONFIG1_CLKACTIVATIONTIME(1) during init. > > But aren't we deciding number of ticks based on clock period ? > If we take case of onenand, based on the knowledge of clock period, > number of ticks are calculated. > > And similarly to decide cycle2cycledelay, busturnaround, we decide number > of ticks based on peripheral datasheet timings & gpmc clock, hence > shouldn't it also be dynamically calculated similar to timings that were > existing earlier.
Hmm indeed onenand is setting that dynamically. OK, let's try your approach and make sure we patch in the missing values so we don't overwrite the values set with gpmc_cs_write_reg. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
