Santosh Shilimkar 8f0de0d62f ARM: OMAP2+: Get rid of custom OMAP_32K_TIMER_HZ ... The timekeeping doesn't depend on HZ value in presence of fine grained clocksource and hence there should not be any time drift because of HZ value which was chosen to be divisor of 32768. OMAP has been using HZ = 128 value to avoid any time drift issues because of 32768 HZ clock. But with various measurements performed with HZ = 100, no time drift is observed and it also proves the point about HZ not having impact on time keeping on OMAP. Very informative thread on this topic is here: https://lkml.org/lkml/2013/1/29/435 Special thanks to John Stulz, Arnd Bergmann and Russell King for their valuable suggestions. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Russell King <linux@arm.linux.org.uk> Cc: John Stultz <john.stultz@linaro.org> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>		2013-02-01 14:51:22 -08:00
..
include/plat	ARM: OMAP2+: Get rid of custom OMAP_32K_TIMER_HZ	2013-02-01 14:51:22 -08:00
counter_32k.c	ARM: OMAP: 32k counter: resolve sparse warnings	2012-12-28 02:09:01 -07:00
debug-leds.c	ARM: OMAP: debug-leds: Use resource_size instead of hard coded macro	2012-11-12 13:28:28 -08:00
dma.c	ARM: drivers: remove __dev* attributes.	2013-01-03 15:57:04 -08:00
dmtimer.c	ARM: drivers: remove __dev* attributes.	2013-01-03 15:57:04 -08:00
i2c.c	Revert "ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints"	2012-11-14 11:54:41 +01:00
Kconfig	ARM: OMAP2+: Get rid of custom OMAP_32K_TIMER_HZ	2013-02-01 14:51:22 -08:00
mailbox.c	workqueue: deprecate flush[_delayed]_work_sync()	2012-08-20 14:51:24 -07:00
Makefile	ARM: arm-soc: late cleanups for omap	2012-12-30 09:59:21 -08:00
sram.c	ARM: OMAP: SRAM: resolve sparse warnings	2013-01-01 15:42:00 -07:00