Thread (2 messages) 2 messages, 2 authors, 2013-06-28

[linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup

From: Thomas Gleixner <hidden>
Date: 2013-06-28 14:02:30
Also in: lkml

On Fri, 28 Jun 2013, ?? wrote:
quoted
The A10 manual from http://free-electrons.com/~maxime/pub/datasheet/
does not seem to contain any details about what bad things may happen
if we try to read CNT64_LO_REG while latching is still in progress and
CNT64_RL_EN bit in CNT64_CTRL_REG has not changed to zero yet.
I can imagine the following possible scenarios:
 1. We read either the old stale CNT64_LO_REG value or the new
    correct value.
 2. We read either the old stale CNT64_LO_REG value or the new
    correct value, or some random garbage.
 3. The processor may deadlock, eat your dog, or do some other
    nasty thing.

In the case of 1, we probably can get away without using any spinlocks?
About the 64bits counter, the latch bit is needed because of the asynchronous circuit.
The internal circuit of 64bits counter is working under 24Mhz clock, and CNT_LO/HI
is read with APB clock. So the clock synchronize is needed. The function of the latch
is synchronous the 64bits counter from 24Mhz clock domain to APB clock domain.
So, if the latch is not completely, value of the CNT_LO/HI maybe a random value, because
some bits are latched, but others are not. So, the CNT_LO/HI should be read after
latch is completely.
The latch just takes 3 cycles of 24Mhz clock, the time is nearly 0.125 micro-second.
I really wonder why we're trying to use that timer. AFAICT the A10 has
another six 32bit timers which do not have this restriction and the
clocksoure/sched_clock implementation works nicely with 32 bits. So
what's the point of using that 64 bit counter if it's horrible to
access?

Thanks,

	tglx
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help