On 06.11.2012 21:20, Russell King - ARM Linux wrote:

quoted

With the change, it still wraps at 2 seconds.

And there's no way that such a change could ever go into mainline; it
can mean that the timer is registered into the timer subsystem before
the timer subsystem has been initialised.  That's why we postpone that
part to time_init().

Sure, I just wanted to quick-check whether it helps or not, this was
not meant as a solution for anything.

This gets interesting. The same code on slightly different hardware
(but using same source files), just 32-bits so it wraps around after
~1,5 days:

sched_clock: 32 bits at 32kHz, resolution 31250ns,
  wraps every 134217727ms

works without problem here:
  [134919.008468] PHY: imx28-fec-1:00 - Link is Up - 100/Full

(134919 > 134217).

The only difference is 32 bits instead of 16 and a different
function to read the hardware.

Well.  I just tried an experiment with OMAP4:
[    0.000000] sched_clock: 16 bits at 32kHz, resolution 30517ns,

wraps every 1999ms

...
[    3.070404] Freeing init memory: 192K

OK, so it is not a 16-bit problem either. So where is the
difference? Could it be that HZ / NO_HZ is playing some
tricks here and need to be taken into consideration?

I'll try to artificially limit the counter-reading function
on my hardware to 16 bits and look whether I can also
reproduce this - probably on Thursday or Friday earliest
(busy with other tasks now).

If it works I'll resubmit for only the iMX.28 and someone
who actually has the iMX.23 hardware to experiment with has
to look at it; the best start is probably to start with
comparing it to the working OMAP4. If it does not I'll
try to find the culprit.

Thanks
-- 
                                    Stano