Thread (50 messages) 50 messages, 3 authors, 2012-06-15
STALE5120d
Revisions (11)
  1. v1 [diff vs current]
  2. v1 [diff vs current]
  3. v1 [diff vs current]
  4. v1 [diff vs current]
  5. v1 [diff vs current]
  6. v1 current
  7. v1 [diff vs current]
  8. v2 [diff vs current]
  9. v3 [diff vs current]
  10. v4 [diff vs current]
  11. v5 [diff vs current]

[PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings

From: Mohammed, Afzal <hidden>
Date: 2012-06-14 09:41:51
Also in: linux-omap

Hi Tony,

On Thu, Jun 14, 2012 at 14:59:57, Tony Lindgren wrote:
* Afzal Mohammed [off-list ref] [120611 07:21]:
quoted
+	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.

Regards
Afzal
Writing these over and over again during DVFS does not make sense, they
should be only initialized once.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help