Thread (9 messages) flat view 9 messages, 2 authors, 2010-12-19
STALE5696d

Revision v1 of 5 in this series.

Revisions (5)
  1. v1 [diff vs current]
  2. v1 [diff vs current]
  3. v1 [diff vs current]
  4. v1 [diff vs current]
  5. v1 current

Re: [PATCH 0/40] Complete set of clocksource/sched_clock patches

From: Mikael Pettersson <hidden>
Date: 2010-12-19 16:15:09
Also in: linux-arm-kernel, linux-samsung-soc

Possibly related (same subject, not in this thread)

Russell King - ARM Linux writes:
 > >  >  Does trr need to be written in
 > >  > ->set_mode (if so that's another bug in this code)?
 > > 
 > > trr{0,1} need not and should not be changed after iop_time_init().
 > 
 > It sounds like trr0 needs to be written in ->set_mode's
 > CLOCK_EVT_MODE_PERIODIC path then, because with my patch, we never set
 > this register.

Hmm, yes, your patch does cause that. I think it's better to keep the
write_trr0() in iop_init_time(), but move it ahead of the
clockevents_register_device() call; this avoids a needless reinitialization
of trr0 in ->set_mode's CLOCK_EVT_MODE_PERIODIC case. Writing to trr0 is safe,
it's only the early write to tmr0 that's dangerous.

My kernel survived that bug because I have CONFIG_NO_HZ=y so the clockevents
timer is always(?) reprogrammed into oneshot-mode, which doesn't use trr0.

 >  Or will trr0 be updated when we write tcr0 ?
 
No, only explicit write_trr0() calls can update trr0.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help